|
Notes |
|
|
(0017712)
|
|
zed
|
|
06-12-2016 12:12
|
|
|
Интерфейс зависает полностью или только карта? На других зумах проблем нет? Запустите дебажную версию и после зависания подождите минуту, до появления сообщения об ошибке. |
|
|
|
(0017713)
|
|
Gromov
|
|
06-12-2016 12:30
|
|
|
Интерфейс зависает полностью, остается только принудительно снимать задачу. Где можно скачать дебажную версию, я попробую получить сообщение об ошибке. |
|
|
|
(0017714)
|
|
zed
|
|
06-12-2016 12:32
|
|
|
Идёт в составе ночной сборки (SASPlanet.Debug.exe), отчёт об ошибке (файл с расширением *.elf) появляется в папке с программой. |
|
|
|
(0017716)
|
|
Gromov
|
|
06-12-2016 23:39
|
|
|
Запустил дебажную версию, отчет об ошибке загрузил. |
|
|
|
(0017717)
|
|
zed
|
|
07-12-2016 06:19
|
|
Почему-то случается дедлок в TViewPortState.ChangeViewSize - во время смены зума с анимацией срабатывает событие TfrmMain.mapResize, которое вызывает этот метод и пытается захватить блокировку, в то время как TViewPortState.ChangeZoomWithFreezeAtVisualPointWithScale ещё не отработала и не освободила блокировку.
Gromov
Отключите опцию "Вид - Анимация при масштабировании", должно помочь, пока с дедлоком не разберёмся. |
|
|
|
(0017718)
|
|
Gromov
|
|
07-12-2016 07:30
|
|
|
Действительно, помогло. Спасибо! |
|
|
|
(0017782)
|
|
Gromov
|
|
23-01-2017 01:13
|
|
|
Теперь, на версии 170113.9655 - даже при отключении опции "Вид - Анимация при масштабировании" происходит зависание. |
|
|
|
(0017783)
|
|
zed
|
|
23-01-2017 05:50
|
|
Сделайте отчёт об ошибке, как в прошлый раз.
И уточните, баг только на зумах 9 <-> 10? |
|
|
|
(0017784)
|
|
Gromov
|
|
26-01-2017 22:34
|
|
|
Приложил отчет об ошибке, баг только на зумах 9 <-> 10. |
|
|
|
|
Я, кажется, понял в чем проблема. Классический дедлок связанный с рекурсивным вызовом примитива синхронизации не поддерживающего рекурсивных вызовов. Да еще и при редком стечении обстоятельств. Проблема в TViewPortState. В том что у него есть и блокировка FCS, и FView со своим вызовом уведомлений подписчиков под этой блокировкой.
Как всегда исправить можно кучей разных способов:
Можно сделать FCS поддерживающим рекурсивные вызовы. Это несколько смягчит, но, как мне кажется, не исправит проблему полностью, потому что в свое время я не рассчитывал TViewPortState на повторные вхождения и может вылезти что-то еще. А может и не вылезти.
Можно вынести изменение FView из под блокировки. Но тогда может возникнуть хитрая ситуация гонки, если два потока вызвали изменение TViewPortState и действия одного из них просто потерялись, потому что он пользовался еще не обновленным значением FView.
Можно поковырять ILocalCoordConverterChangeableInternal и сделать, что бы обязанностью вызывать нотификаторы подписчиков было у изменяющего. То есть SetConverter изменяет значение, но не дергает нотификаторы, а только возвращает bool указывающий на необходимость этого, а уже TViewPortState дергает добавленный метод DoNotify после освобождения блокировки. |
|
|
|
(0017786)
|
|
vdemidov
|
27-01-2017 07:29
(edited on: 27-01-2017 07:39) |
|
А еще можно сделать TViewPortState наследником TLocalCoordConverterChangeable и вообще избавиться от лишней блокировки FCS.
ИМХО так будет даже правильнее, хотя я обычно предпочитаю аггрегацию наследованию.
PS: разделение этих сущностей в разные объекты было сделано очень давно и с тех пор многое изменилось. Теперь такое разделение выглядит совсем неоправданным.
|
|
|
|
(0017788)
|
|
zed
|
|
28-01-2017 16:01
|
|
|
|
|
|
|
|
|
|
|
Вроде бы исправил причину дедлока. Проверяйте в следующей ночнушке. |
|
|
|
(0017791)
|
|
Gromov
|
|
30-01-2017 01:10
|
|
|
Проверил, версия SAS.Planet.Nightly.170128.9656 - все работает даже с анимацией. |
|
SASPlanet.Debug.elf (92,484) 06-12-2016 23:37