View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0002301 | SAS.Планета | Баг / Bug | public | 28-12-2013 21:06 | 29-01-2014 19:04 |
| Reporter | dmytro_ovdiienko | Assigned To | zed | ||
| Priority | normal | Severity | major | Reproducibility | sometimes |
| Status | resolved | Resolution | fixed | ||
| Platform | Windows | OS | XP | OS Version | SP3 |
| Product Version | 131111 | ||||
| Target Version | 140303 | Fixed in Version | 140303 | ||
| Summary | 0002301: Залипания во время просмотра карты | ||||
| Description | В какой-то момент начинает жутко тормозить выкачка тейлов во время просмотра карты. Слои OSM MAPNIK и OSM Mapsurfer. Когда с ними все плохо, перехожу на OSM CycleMap. Но тогда и он начинает тупить. И вроде как начинаю думать на тормоза OSM сервера, но в браузере никаких тормозов нет. Если же SASPlanet закрыть и открыть по новой, все сразу начинает летать. В чем может быть проблема? Может это зависание всех воркеров выкачки тейлов? Если да, можно как-то очистить очередь задач? | ||||
| Tags | No tags attached. | ||||
| Attached Files | |||||
| related to | 0001103 | closed | vdemidov | Останавливается скачивание тайлов для вывода на экран |
| related to | 0002312 | resolved | zed | Очередь загрузки тайлов видимой области обнуляется через 30 секунд, даже если тайлы ещё не загрузились |
| child of | 0002307 | resolved | zed | В процессе закачки видимой области "моргают" тайлы |
|
|
Вот опять залипло. "Queue: 0". И почемуто только OSM MAPNIK и Mapsurfer. Слои Bing или OSM CycleMap не глючат. Перезапуск программы решает проблему. |
|
|
Аналогично. Всё собирался создать инц., да грешил на свою машину. Если достаточно долго (мин. 5--10) сёрфить по любой карте -- она сначала начинает тормозить, а потом перестаёт скачиваться вовсе. При этом загрузка по области (если запущена параллельно) продолжается, как ни в чём не бывало. Замечено в течение последнего года на разных версиях, в т.ч. ночнушках. Перезагрузка помогает всегда. Win-vistahome. |
|
|
Проверьте воспроизводимость на текущей ночнушке. |
|
|
Воспроизводится. |
|
|
У меня не воспроизводится. Можно по шагам, на чистой ночнушке? |
|
|
Сложно объяснить... Просто выбираю OSM MAPNIK и дергаю карту туда сюда на монике с разрешением 1680*1080. В какойто момент карта перестает загружаться. Переключаюсь на mapsurfer. Опять дергаю туда-сюда. И эта зависает. Переключение опять на MAPNIK н помогает. Может сделать каокй-то билд, к которому можно было бы подключиться дебагером и получить дамп? А дамп потом можно было бы посмотреть у тебя на машине. |
|
|
В ночнушке идёт SASPlanet.Debug.exe который ловит ошибки, но если там что-то тихо-мирно просто висит, то тут мало что поможет. Раз проблема только на OSM, наверное имеет смысл сделать дамп запросов на сервер любым снифером. Может там что-то крайне неожиданное прилетает от сервера и сокет просто остаётся в подвешенном состоянии. И можно попробовать в zmp ограничить или наоборот увеличить число подключений к серверу (MaxConnectionsCount) и прописать в хидерах "Connection: Close". Но не факт, что проблема в http-стеке. Может просто глючит очередь или ещё в одном из тысячи возможных мест... |
|
|
А еще, возможно просто есть отличие между отправляемым САС.Планетой запросом и запросом из браузера. И сервер по этой разнице начинает банить такие запросы. |
|
|
Может какие-то логи добавить для отладки? |
|
|
"У меня не воспроизводится. Можно по шагам, на чистой ночнушке?" вчерашняя 1400110 -- воспроизводится, м.б. чуть позже, чем на прошлогодних. По шагам: запускаю САС, выбираю карту (в моём случае это любые спутники, вчера тестировал на Imagery2) и стрелочками двигаю карту (z16, если важно) вверх, вниз, влево, вправо. Минут 5--7 всё летает, потом начинает подтормаживать, а минут через 15--20 от начала и вовсе встаёт (именно эта карта, которая тестировалась -- остальные поначалу помогают растормаживать и с ними всё нормально, а потом только другие и качаются). Принудительная загрузка конкретных тайлов (на правой кнопке) работает, т.е. тормоза не абсолютные, а только на сёрфинг. И, как я говорил выше, закачка по областям тоже работает нормально. |
|
|
> и стрелочками двигаю карту (z16, если важно) вверх, вниз, влево, вправо Так может клинит именно это перемещение? Плавную анимацию отключать пробовали? |
|
|
Да, есть такое-то странное поведение на этой карте. До полного "залипания" довести ситуацию не получилось, но то, что тайлы начинают качаться медленно и не все, это факт. Причём, все запросы ушедшие на сервер возвращаются с 200 ОК, но вот очередь тайлов может быстренько скатиться до 0 (с 32-х), скачав при этом всего несколько тайлов. |
|
|
Понял почему счётчик слетает до нуля. Если загрузка тайлов очень медленная (по 15 сек. на тайл), то по TTL (30 сек.) этот поток будет успешно прибит и очередь обнулится. Но вопрос, почему эти тайлы начинают вдруг так медленно качаться, остаётся открытым. |
|
|
"Так может клинит именно это перемещение?" -- нет, программе равно, чем её перемещают, мышкой или клавой. "Плавную анимацию отключать пробовали?" -- не отключается. Там есть "Аним. при масштабировании" -- она у меня выключена по умолчанию. И есть "Движение по инерции" -- вот оно, будучи выключенным, всё равно продолжается. Вер: 140110.7793. Кстати, обратный счётчик показывает цены на яхты, но где-то не здесь. Впрочем, это отдельный баг и оформлять его нужно соотв. ) |
|
|
Со счётчиком всё в порядке. |
|
|
В общем, полечил загадочное поведение 0002301:0013549, а по поводу снижения скорости загрузки, я без понятия. У меня это торможение наблюдается практически сразу после запуска (RAM-кэш + активная смена зума и позиции, не дожидаясь окончания загрузки тайлов). Но снифером видно, что все потоки качают, но сервер отдаёт очень медленно. Ну, или может это мы вдруг начинаем спать между приёмом пакетов - но с чего бы? Тем более, что при закачке того же гугла всё летает. |
|
|
И после рестарта приложения все опять работает без тормозов. И выкачка региона тайлов, как говорит gma, работает нормально. Чем отлиается реализация выкачки региона и экрана? |
|
|
> И после рестарта приложения все опять работает без тормозов. Перезапуск не обязательное условие. Можно просто переключиться на другую карту и/или подождать некоторый таймаут, пока SAS не закроет все соединения с этим сервером или пока сервер не решит, что можно уже и не тормозить. > И выкачка региона тайлов, как говорит gma, работает нормально. Чем отлиается реализация выкачки региона и экрана? У меня эти вещи работают одинаково медленно. И реализация там ничем не отличается - закачка идёт через одну и туже очередь. |
|
|
С перезапуском ты продолжаешь работать с той же картой. То есть, врядли это тормоза на стороне сервера. Можно посчитать задержку между прибытием пакета на сетевуху и появлением ее на экране. |
|
|
А вот у меня, перезапуск не помогает. Только что проверил. Видно я сегодня за вечер уже порядком поднадоел серверу. > Можно посчитать задержку между прибытием пакета на сетевуху и появлением ее на экране. Вы для начала, посчитайте скорость прибытия пакетов на сетевуху. Т.е. нужны убедительные доказательства, что это тормозит не сервер и что это не проявления своеобразного бана. А то, что в браузере всё работает - совсем не показатель. Там же куки и все дела, а тут - робот. |
|
|
Дело в том, что скорость прибытия пакетов на сетевуху зависит от скорости их выкачки. Если приложение тормозит, то и на той стороне посылают с задержкой. |
|
|
Ок. попробую посчитать скорость ответа на HTTP запрос |
|
|
Поставьте кэширующий прокси между SAS и сервером. Пускай прокси выкачивает без задержек, если у него получится и отдаёт тайлы SAS-у. |
|
|
Похоже, тормозит именно SAS. Ответ от WEB сервера приходит сразу. А вот новые запросы SAS отправляет с задержкой. Ща выложу лог проксисервера и попробую поснифить. Хм... может в системе не хватает ресурсов. Может надо стараться переиспользовать сокеты? |
|
|
Keep-Alive же? |
|
|
Вот к примеру залип на 3 сек начиная с "!-<12/01 21:11:25". |
|
|
>Keep-Alive же? В логе видно, как выделяются постоянно новые ТЦП порты |
|
|
Запись "!->12/01 21:11:27 [127.0.0.1:61011>3128] (t3 421) >Proxy in:7426 out:253 " похоже означает закрытие сокета на строне SAS. |
|
|
> Ответ от WEB сервера приходит сразу Приход ответа, это не мгновенная операция в любом случае. И из ваших логов можно только увидеть, когда ответ начал приходить, но не видно, когда же он пришёл целиком. У меня некоторые тайлы по 20 секунд грузились и в снифере было хорошо видно, как приходят "пакеты". |
|
|
> В логе видно, как выделяются постоянно новые ТЦП порты Значит виноват прокси. Через снифер порты не выделяются и я наблюдаю честный Keep-Alive (OSM MAPNIK). |
|
|
И для тестов лучше в zmp прописать MaxConnectToServerCount=1 и в скрипте убрать генерирование a/b/c префиксов в url (и слать всегда, скажем, на "а"). |
|
|
У меня, кстати, было опять начало качать быстро, но насёрфив около 800 тайлов оно таки начало тормозить. Хотя всё шло в один поток и с Keep-Alive. И после перезапуска SAS, оно хоть и начало ходить через другой порт, но всё так же медленно, с самого же первого тайла. Так что тут (конкретно на карте OSM MAPNIK), SAS однозначно ни при чём. |
|
|
Поймал зависон. Ваершарк показвыает, что никаких пакетов со стороны SAS не уходит. У мну WinXP SP3. |
|
|
А через 58сек соединение с OSM закрылось. На попытки подвигать карту OSM никак не реагирует. Закрытие подключения инициировал OSM. |
|
|
> никаких пакетов со стороны SAS не уходит Это скорее всего баг с очисткой очереди 0002312 - нужно проверять в завтрашней ночнушке. > На попытки подвигать карту OSM никак не реагирует Т.е. не отвечает на запросы или SAS их не шлёт? |
|
|
SAS не завис. На мышь и клаву реагирует. Просто не шлет запросы на веб сервер. |
|
|
А этот баг с очисткой очереди, как-то объясняет, почему, если переключиться на другую карту, то она работает? |
|
|
Да. Но этот баг на смещение карты не завязан, т.е. закачка должна была возобновиться. |
|
|
Я ждал минуты 4-5. Закачка не возобновилась. |
|
|
Она должна была начаться мгновенно после смещения карты (если конечно в кэше тайлов нету). А по логу (sas-osm) я никаких замечаний не вижу. |
|
|
> Она должна была начаться мгновенно после смещения карты (если конечно в кэше тайлов нету). Я переключил SAS в режим Internet. Кеш не должен был использоваться. Но по ощущениям, SAS еще кеширует в памяти. Еще я в ZMP добавил MaxConnectToServerCount=1, но подключений было 3шт (судя по pcap файлу) > А по логу (sas-osm) я никаких замечаний не вижу. Ага. Ничего необычного. Но на последнем тайле все наглухо остановилоась и SAS больше не пробовал что-либо качать. |
|
|
>но подключений было 3шт (судя по pcap файлу) Потому что у сервера алиасы a/b/c: a.tile.openstreetmap.org b.tile.openstreetmap.org c.tile.openstreetmap.org и я рекомендовал исправить скрипт, чтобы оно всегда шло на a.tile.openstreetmap.org >Но по ощущениям, SAS еще кеширует в памяти Да, где-то в конфигах есть переменная TileMaxAgeInInternet |
|
|
Предлагаю нашпиговать SAS логами и выдать мне на растерзание. |
|
|
Надо подумать, что именно мониторить. Попробуйте завтра взять ночнушку, включить у карты RAM-кэш и в режиме интернет+кэш погонять до посинения. Почему RAM-кэш, а не просто режим Интернет? Потому что у первого есть конфиги, доступные через zmp: UseMemCache - использовать кэш в памяти (при CacheType=9 (RAM-кэш) отключение данной опции приведёт к ошибке), включено по-умолчанию MemCacheCapacity - количество тайлов кэшируемых в память. По-умолчанию = 100 MemCacheTTL - время жизни тайлов (в миллисекундах), кэшируемых в память. По-умолчанию = 60000 мс. (1 мин.) MemCacheClearStrategy - стратегия очистки (по TTL) кэшируемых в память тайлов. Принимает значения: 0 - удалять ВСЕ тайлы из мем-кэша, если истёк TTL у самого СТАРОГО тайла; 1 - удалять ВСЕ тайлы из мем-кэша, если истёк TTL у самого МОЛОДОГО тайла; 2 - удалять только те тайлы, у которых истёк TTL. По-умолчанию включён режим 1. RestartDownloadOnMemCacheTTL - автоматически перезакачивать тайлы в пределах видимой области экрана при очистке мем-кэша (работает только если UseMemCache=1). По-умолчанию отключено. Описание формата пользовательских карт zmp |
|
|
Кстати, в режиме Интернет, оно пишет в кэш и перезаписывает существующие тайлы. Возможно каким-то боком зависает запись в кэш, а все потоки его дружно ждут. |
|
|
Это объясняет, почему другие карты продолжают работать? |
|
|
Для включения RAM Cache нужно добавить в zmp только это? UseMemCache=1 |
|
|
> Это объясняет, почему другие карты продолжают работать? Зависание кэша? Естественно - у каждой карты свой кэш и своя качалка. > Для включения RAM Для включения - достаточно в гуе зайти в настройки карты (Ctr+Alt+P) и выбрать "Тип кэша - ОЗУ". А в zmp можно уменьшить MemCacheTTL до 15000 (15 секунд) или количество кэшируемых тайлов. Но это уже на усмотрение. |
|
|
Ок. Завтра проверю. |
|
|
И вдогонку, по тем же 3 кнопкам Ctr+Alt+P, в самом низу есть надпись: "Разрешено скачивание" и в поле - "Да". Так вот, когда оно перестанет качать, загляните сюда, возможно оно там что-то интересное напишет. |
|
|
Воспроизвел на SAS.Planet.Nightly.140113.7797. Кеш - RAM. Когда зависло, размер очерели == 0 и при перемещении карты не увеличивался. Похоже, что SAS не добавляет тайлы в очередь. |
|
|
Мне кажется, где-то увеличивается счетчик подключения к серверу и не декрементируется. |
|
|
Приложил сборку для тестов. Запустить Dbgview.exe, затем SASPlanet.exe, добиться зависания и сбросить лог дебагера сюда. Дебажные сообщения выводятся только для одного класса TUiTileDownload, на всякий случай в архиве исходник этого класса, где видно когда и какие сообщения выводятся (и какие вообще могут быть). Сообщения с текстом "Nothing to do", кроме "Nothing to do: if VNeedDownload" когда тайлы есть в кэше, следует рассматривать как крайне подозрительные. |
|
|
Во время загрузки в лог что-то должно выводиться? Я запустил, скачал несколко тайлов, но ничего не вижу в dbgview |
|
|
Да, должны бежать строчки очень активно. |
|
|
Не пишет. Моя программа пишет, а SAS - не пишет. #include <Windows.h> int main() { OutputDebugString("123\n"); } |
|
|
Вот блин :( Вариант - скачать виртуалку http://yadi.sk/d/bZ3bEBzMC2biN и попробовать запустить там. Тем более, там вы при желании сможете запустить SAS прямо под отладчиком и посмотреть как минимум на имена потоков и их наличие в момент бага. Ну и брекпоинты, тоже полезная вещь. |
|
|
файлы от 27.03.2013.. это точно последнее? |
|
|
У меня есть CBuilder6. Дай плз сурсы от SAS.Planet.Nightly.140113.7797 |
|
|
Нашел сурсы. Что выполняется при перемещении карты? Где бряки ставить? |
|
|
Мне кажется вы фигней занимаетесь. В первую очередь нужно проверить где затык: в сервере, подсистеме загрузки или в загрузчике видимой области. Последний отсекается очень просто. После того как тайлы качаться перестали нажимаем Ctrl-A и запускаем скачивание текущего экрана как области. Если качается, то ошибка именно в загрузке видимой области, если нет, то в подсистеме загрузки. |
|
|
>файлы от 27.03.2013.. это точно последнее? В виртуалке - старые исходники и компоненты, но их легко обновить: - зайти в папку c:\SASPlanet и выполнить в консоли 2 команды "hg pull" (затянуть свежие сорцы с сервера) и "hg update -C" (применить обновление и отбросить локальные изменения) - зайти в папку C:\Program Files\CodeGear\RAD Studio\5.0\lib_sas, удалить папку pascalscript и выполнить те же 2 команды: "hg pull" и "hg update -C" После этого можно запускать SASPlanet.dpr. >У меня есть CBuilder6 Не подойдёт. >Что выполняется при перемещении карты? В u_UiTileDownload.pas вызывается TUiTileDownload.OnPosChange; Соответственно, поток который ставить тайлы в очередь закачки, будет называться TUiTileDownload (он создаётся вот так: VDownloadTask := TBackgroundTask.Create) Очередь запросов в u_InterfaceQueue.pas, поток, который обрабатывает очередь - u_TileRequestQueueProcessorThread.pas (имя потока в дебагере TTileRequestQueueProcessorThread, количество потоков во время загрузки ограничено значением MaxConnectToServerCount). |
|
|
>нужно проверить где затык: в сервере, подсистеме загрузки или в загрузчике видимой области Сервер уже исключили. И очень большое подозрение именно на загрузчика видимой области (читай второе сообщение 0002301:0013453), именно на него (TUiTileDownload) я и натыкал дебажных сообщений, чтобы понять, где там может быть затык. У себя я так и не смог воспроизвести, поэтому вся надежда на dmytro_ovdiienko |
|
|
dmytro_ovdiienko И да, если будете расставлять бряки в отладчике, то в папке Maps лучше оставить только одну карту, иначе в OnPosChange будут прилетать мусорные сообщения от всех остальных карт. |
|
|
>Сервер уже исключили. И очень большое подозрение именно на загрузчика видимой области (читай второе сообщение 0002301:0013453), именно на него (TUiTileDownload) я и натыкал дебажных сообщений, чтобы понять, где там может быть затык. Ну так я и описал способ в этом убедиться на 100% даже без отладчика. |
|
|
Ну убедились, а дальше что? Как баг найти? |
|
|
Ок. Я сначала еще раз проверю, что поблема в выкачке. Потом буду дебажить. Хотя не уверен, что у меня получится это на виртуалке. На Win7, например, почему-то не воспроизводится. Может, это какаято особенность моей ОС. |
|
|
И мне нужны исходники того кода, с которым собирался Дебаг, который мне выдал zed. |
|
|
Я уже объяснил, как получить сорцы 0002301:0013607, а единственное отличие моего дебага - изменения в u_UiTileDownload.pas, который я также приложил в аттаче. Так что заменив его, вы получите идентичную копию сборки. |
|
|
> Ну убедились, а дальше что? Как баг найти? Точно убедились? Я не уверен, что баг именно в TUiTileDownload. Не так уж много там кода. |
|
|
Тут одно из двух: либо прилетает OnPosChange и где-то в TUiTileDownload не обрабатывается, либо не прилетает и тогда проблема выше. |
|
|
> Тут одно из двух: либо прилетает OnPosChange и где-то в TUiTileDownload не обрабатывается, либо не прилетает и тогда проблема выше. Если бы это было бы так, то не было бы такого: > Вот опять залипло. "Queue: 0". |
|
|
Именно такое и было бы :) |
|
|
Я про "либо не прилетает" |
|
|
Да в обоих случаях счётчик будет стоять на нуле. Ты посмотри, где он увеличивается. |
|
|
Если бы не прилетало событие, тогда другие карты тоже бы не работали. Верно? |
|
|
Если карта вдруг не отписалась от уведомлений, то да. Вот и выходит, что затык в TUiTileDownload. |
|
|
А она может отписаться? |
|
|
Отписка происходит только в момент уничтожения карты (TUiTileDownload.Destroy), поэтому, практически - нет. |
|
|
"После того как тайлы качаться перестали нажимаем Ctrl-A и запускаем скачивание текущего экрана как области" -- Дождался затыка, запустил закачку области -- пошла на ура на хорошей скорости. Экран после этого всё равно не завёлся. |
|
|
Имхо чем пытаться починить TUiTileDownload лучше сразу его переписать полностью. То есть завести массивчик отправленных запросов и итератор тайлов как поля объекта. Убрать оттуда отдельный поток для каждой карты, а завести один поток на все карты, который будет дергать активные. Выкинуть тот семафор нафиг. И тд. |
|
|
>Дождался затыка, запустил закачку области Удалось ли собрать дополнительную информацию при помощи dbgview во время затыка? >Имхо чем пытаться починить TUiTileDownload лучше сразу его переписать полностью Поскольку неизвестно в чём баг, то нет никаких гарантий, что ты его не перенесёшь в новую реализацию. Сейчас по твоим словам реализация простая до предела и глючить там нечему (а оно таки глючит), но предлагаешь усложнить реализацию на порядок, в надежде избавиться от глюка. Где логика? Хотя, несомненно, ты можешь попробовать всё переписать как запланировал, возможно и поможет. Но dmytro_ovdiienko и gma я бы попросил продолжить поиск бага в текущей реализации, а не ждать нового движка от vdemidov. Мне кажется, что OnPosChange должен прилетать и скорее всего мы стартуем поток, но где-то в if/then с завидным постоянством выходим в отсутствующий else блок (куда я напихал OutpuDebugString) и ничего не делаем. И это может быть проблема не собственно TUiTileDownload, а каких-то внешних факторов. |
|
|
gma >Экран после этого всё равно не завёлся И небольшое уточнение терминологии: "затык" это когда карта перестаёт качать и Queue: 0? Показания счётчика в этом случае очень важно. |
|
|
"И небольшое уточнение терминологии: "затык" это когда карта перестаёт качать и Queue: 0? Показания счётчика в этом случае очень важно" -- Да, когда перестаёт качать. Про счётчик я выше уже говорил, что в норме! он показывает количество лун у марса, иногда у земли, но это число ни от чего не зависит. Сегодня на работе скачал Dbw и попробовал добиться результата с ним -- ничего не вышло, качает как миленькая, дошло до почти трёх тысяч (почти час качал) и тут рабочее время кончилось. Но раньше я ОСМ такими объёмами никогда не качал, да и вообще настройки у меня сильно отличаются, не знаю, важно ли это. |
|
|
> Про счётчик я выше уже говорил, что в норме! Что в норме? Он-то в норме, это и так ясно, но должен быть равен нулю, если зависло. Если не равен нулю, значит не зависло, а просто идёт очень медленная загрузка тайлов в фоне. > он показывает количество лун у марса, иногда у земли, но это число ни от чего не зависит. А я вам ответил, что со счётчиком всё в порядке. Может вы просто не понимаете, что он отображает или перевод вводит в заблуждение. В английском варианте этот счётчик называется Queue - Очередь. В него записывается число тайлов поставленных в очередь на загрузку. Каждая карта имеет свою собственну очередь, но счётчик показывает суммарное число для всех отображаемых карт. К тому же, есть ещё такой момент - для каждой карты введён лимит на количество тайлов, одномоментно находящихся в очереди. И по-умолчанию этот лимит равен 32. Таким образом, если включена одна карта на HD мониторе, то для загрузки экрана нужно скачать порядка 50 тайлов. Карта ставит в очередь 32 штуки и ждёт, пока скачается хотя бы один. В этот момент счётчик показывает эти самые 32. Как только тайл скачался, счётчик становится 31, карта тут же добавляет ещё один тайл в очередь и опять ждёт. При этом операция может произойти настолько быстро, что смены цифр 32 - 31 - 32 вы можете и не увидеть, поэтому некоторое время в Queue будет отображаться 32, а потом начнёт падать до нуля. Или может закачаться сразу 4 тайла (по-умолчанию каждая карта качается в 4 потока), тогда счётчик упадёт до 28, а потом опять увеличится до 32 и уже это изменение счётчика вы можете заметить. Соответственно, если включены 2 карты, то счётчик будет крутиться возле 64-х и не выше, хотя вообще, нужно загрузить 100 тайлов (условно), чтобы обновить экран. |
|
|
"если включены 2 карты, то счётчик будет крутиться возле 64-х и не выше" -- включена как правило одна карта, лун у марса две, у земли -- одна, вот примерно эти числа он мне и показывает чаще всего, иногда 7, 4 или другое что, но логики в его показаниях я не могу найти. В скачанном дебаге САСовый счётчик показывал всё правильно, у меня он может полчаса показывать единицу, независимо от происходящего на экране. |
|
|
Остановка закачки в Ui может происходить на разных картах.У меня например наблюдается для спутника Гугла после скачки нескольких тысяч тайлов. После остановки, под отладчиком нашел "подозрительные" места в коде: -в модуле TBackgroundTask в процедуре Execute в строке 134 переменная VOperatonID принимает значение 0. -в результате в модуле TUiTileDownload в процедуре DoProcessDownloadRequests в строке 377,378 происходит обход кода закачки. Если закачка идет, VOperatonID имеет значение не равное 0. |
|
|
> в модуле TBackgroundTask в процедуре Execute в строке 134 переменная VOperatonID принимает значение 0 Значит поток был только что создан и это первая задача. 0 - абсолютно нормальное значение. > в результате в модуле TUiTileDownload в процедуре DoProcessDownloadRequests в строке 377,378 происходит обход кода закачки Имеется в виду проверка "if ACancelNotifier.IsOperationCanceled(AOperationID) then"? Первый раз может и сработать, если карта движется и прежде чем мы дошли до этой строчки у нас уже успела стартануть новая задача (должны были прилететь вот сюда, отменить старую задачу и увеличить счётчик следующей операции). И обновите свою версию исходников, сейчас на строках 377,378 выполняются совсем другие операции. |
|
|
> Имеется в виду проверка Да, эта самая проверка(нов 407 строка). Попробую повторить остановку на свежей ночной сборке. Если будет, то и на обновленных исходниках. Проверка на версии SAS 140118.7798 Карта спутник гугл.Остановка произошла на 1926 тайлах,осталось 0. Загрузка по контекстному меню происходит, счетчик при этом увеличивается на 1(1927 и т.д.). Перемещения карты мышкой и стрелками к загрузке не приводят,очередь загрузки стоит на нуле во время перемещений. |
|
|
Если кому-то удастся воспроизвести баг на виртуалке под дебагером, то эту виртуалку можно поставить на паузу и выложить её куда-нить на обменник, а ссылку запостить тут. Я думаю должно сработать. |
|
|
Куда все пропали? Жду логов от дебажной сборки из старого аттача. |
|
|
Словил я его. Висело в WaitForMultipleObjects из-за логической ошибки использования семафора. |
|
|
Спасибо. Теперь, когда проблема найдена, она кажется очевидной, но вот поди ж ты - сколько времени понадобилось что бы ее выловить. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 28-12-2013 21:06 | dmytro_ovdiienko | New Issue | |
| 28-12-2013 22:00 | dmytro_ovdiienko | Note Added: 0013452 | |
| 29-12-2013 08:32 | gma | Note Added: 0013453 | |
| 29-12-2013 11:05 | zed | Relationship added | related to 0001103 |
| 29-12-2013 11:14 | zed | Note Added: 0013456 | |
| 29-12-2013 11:14 | zed | Status | new => feedback |
| 29-12-2013 14:21 | dmytro_ovdiienko | Note Added: 0013457 | |
| 29-12-2013 14:21 | dmytro_ovdiienko | Status | feedback => new |
| 31-12-2013 11:28 | zed | Note Added: 0013474 | |
| 31-12-2013 11:32 | dmytro_ovdiienko | Note Added: 0013475 | |
| 31-12-2013 11:41 | zed | Note Added: 0013477 | |
| 31-12-2013 11:56 | vdemidov | Note Added: 0013478 | |
| 10-01-2014 23:46 | dmytro_ovdiienko | Note Added: 0013533 | |
| 11-01-2014 08:03 | gma | Note Added: 0013535 | |
| 11-01-2014 08:10 | zed | Note Added: 0013536 | |
| 12-01-2014 14:38 | zed | Note Added: 0013549 | |
| 12-01-2014 15:13 | zed | Note Added: 0013550 | |
| 12-01-2014 15:13 | zed | Note Edited: 0013550 | |
| 12-01-2014 17:07 | gma | Note Added: 0013555 | |
| 12-01-2014 17:09 | zed | Note Added: 0013556 | |
| 12-01-2014 17:44 | zed | Relationship added | related to 0002312 |
| 12-01-2014 17:58 | zed | Note Added: 0013557 | |
| 12-01-2014 18:03 | dmytro_ovdiienko | Note Added: 0013558 | |
| 12-01-2014 18:13 | zed | Note Added: 0013559 | |
| 12-01-2014 18:15 | dmytro_ovdiienko | Note Added: 0013560 | |
| 12-01-2014 18:20 | zed | Note Added: 0013561 | |
| 12-01-2014 18:22 | dmytro_ovdiienko | Note Added: 0013562 | |
| 12-01-2014 18:24 | dmytro_ovdiienko | Note Added: 0013563 | |
| 12-01-2014 18:24 | zed | Note Added: 0013564 | |
| 12-01-2014 18:24 | dmytro_ovdiienko | Note Edited: 0013563 | |
| 12-01-2014 19:23 | dmytro_ovdiienko | Note Added: 0013565 | |
| 12-01-2014 19:23 | dmytro_ovdiienko | File Added: http1.log.zip | |
| 12-01-2014 19:24 | zed | Note Added: 0013566 | |
| 12-01-2014 19:25 | dmytro_ovdiienko | Note Added: 0013567 | |
| 12-01-2014 19:26 | dmytro_ovdiienko | Note Added: 0013568 | |
| 12-01-2014 19:28 | dmytro_ovdiienko | Note Added: 0013569 | |
| 12-01-2014 19:41 | zed | Note Added: 0013570 | |
| 12-01-2014 19:42 | zed | Note Added: 0013571 | |
| 12-01-2014 19:45 | zed | Note Added: 0013572 | |
| 12-01-2014 19:59 | zed | Note Added: 0013573 | |
| 12-01-2014 19:59 | zed | Note Edited: 0013573 | |
| 12-01-2014 20:34 | dmytro_ovdiienko | Note Added: 0013574 | |
| 12-01-2014 20:36 | dmytro_ovdiienko | Note Added: 0013575 | |
| 12-01-2014 20:38 | dmytro_ovdiienko | Note Edited: 0013575 | |
| 12-01-2014 20:41 | dmytro_ovdiienko | File Added: sas-osm.7z | |
| 12-01-2014 21:06 | zed | Note Added: 0013576 | |
| 12-01-2014 21:08 | dmytro_ovdiienko | Note Added: 0013577 | |
| 12-01-2014 21:10 | dmytro_ovdiienko | Note Added: 0013578 | |
| 12-01-2014 21:10 | dmytro_ovdiienko | Note Edited: 0013578 | |
| 12-01-2014 21:10 | dmytro_ovdiienko | Note Edited: 0013578 | |
| 12-01-2014 21:11 | zed | Note Added: 0013579 | |
| 12-01-2014 21:13 | dmytro_ovdiienko | Note Added: 0013580 | |
| 12-01-2014 21:16 | zed | Note Added: 0013581 | |
| 12-01-2014 21:21 | dmytro_ovdiienko | Note Added: 0013582 | |
| 12-01-2014 21:27 | zed | Note Added: 0013583 | |
| 12-01-2014 21:30 | dmytro_ovdiienko | Note Added: 0013584 | |
| 12-01-2014 21:37 | zed | Note Added: 0013585 | |
| 12-01-2014 21:38 | zed | Note Edited: 0013585 | |
| 12-01-2014 21:53 | zed | Note Added: 0013586 | |
| 12-01-2014 21:56 | dmytro_ovdiienko | Note Added: 0013587 | |
| 12-01-2014 21:59 | dmytro_ovdiienko | Note Added: 0013588 | |
| 12-01-2014 22:06 | zed | Note Added: 0013589 | |
| 12-01-2014 22:07 | dmytro_ovdiienko | Note Added: 0013590 | |
| 12-01-2014 22:07 | zed | Note Edited: 0013589 | |
| 12-01-2014 22:11 | zed | Note Added: 0013591 | |
| 13-01-2014 19:05 | dmytro_ovdiienko | Note Added: 0013593 | |
| 13-01-2014 19:06 | dmytro_ovdiienko | Note Added: 0013594 | |
| 13-01-2014 19:08 | dmytro_ovdiienko | Note Edited: 0013594 | |
| 13-01-2014 19:56 | zed | File Added: SAS.DeBug.2301.7z | |
| 13-01-2014 20:03 | zed | Note Added: 0013595 | |
| 13-01-2014 20:12 | zed | File Deleted: http1.log.zip | |
| 13-01-2014 20:12 | zed | File Deleted: sas-osm.7z | |
| 13-01-2014 20:14 | dmytro_ovdiienko | Note Added: 0013596 | |
| 13-01-2014 20:15 | zed | Note Added: 0013597 | |
| 13-01-2014 20:20 | dmytro_ovdiienko | Note Added: 0013598 | |
| 13-01-2014 20:28 | zed | Note Added: 0013599 | |
| 13-01-2014 23:49 | dmytro_ovdiienko | Note Added: 0013600 | |
| 13-01-2014 23:53 | dmytro_ovdiienko | Note Added: 0013601 | |
| 14-01-2014 00:12 | dmytro_ovdiienko | Note Added: 0013602 | |
| 14-01-2014 00:29 | dmytro_ovdiienko | Note Edited: 0013602 | |
| 14-01-2014 08:54 | dmytro_ovdiienko | Note Edited: 0013602 | |
| 14-01-2014 08:54 | dmytro_ovdiienko | Note Edited: 0013602 | |
| 14-01-2014 09:08 | vdemidov | Note Added: 0013605 | |
| 14-01-2014 09:19 | zed | Note Added: 0013607 | |
| 14-01-2014 09:23 | zed | Note Added: 0013608 | |
| 14-01-2014 09:53 | zed | Note Added: 0013610 | |
| 14-01-2014 10:11 | vdemidov | Note Added: 0013611 | |
| 14-01-2014 10:14 | zed | Note Added: 0013612 | |
| 14-01-2014 10:20 | dmytro_ovdiienko | Note Added: 0013613 | |
| 14-01-2014 10:28 | dmytro_ovdiienko | Note Added: 0013614 | |
| 14-01-2014 10:32 | zed | Note Added: 0013615 | |
| 14-01-2014 10:48 | vdemidov | Note Added: 0013616 | |
| 14-01-2014 10:50 | zed | Note Added: 0013617 | |
| 14-01-2014 11:40 | vdemidov | Note Added: 0013618 | |
| 14-01-2014 11:41 | zed | Note Added: 0013619 | |
| 14-01-2014 11:50 | vdemidov | Note Added: 0013620 | |
| 14-01-2014 11:51 | zed | Note Added: 0013621 | |
| 14-01-2014 12:49 | dmytro_ovdiienko | Note Added: 0013623 | |
| 14-01-2014 13:04 | zed | Note Added: 0013624 | |
| 14-01-2014 13:30 | dmytro_ovdiienko | Note Added: 0013625 | |
| 14-01-2014 13:38 | zed | Note Added: 0013626 | |
| 15-01-2014 08:40 | gma | Note Added: 0013627 | |
| 15-01-2014 09:40 | vdemidov | Note Added: 0013628 | |
| 15-01-2014 10:27 | zed | Note Added: 0013629 | |
| 15-01-2014 10:31 | zed | Note Added: 0013630 | |
| 15-01-2014 10:39 | zed | Relationship added | child of 0002307 |
| 15-01-2014 16:02 | gma | Note Added: 0013631 | |
| 15-01-2014 16:40 | zed | Note Added: 0013633 | |
| 16-01-2014 10:04 | gma | Note Added: 0013637 | |
| 17-01-2014 21:50 | nvet | Note Added: 0013644 | |
| 18-01-2014 18:44 | zed | Note Added: 0013646 | |
| 18-01-2014 20:16 | nvet | Note Added: 0013648 | |
| 18-01-2014 20:42 | nvet | Note Edited: 0013648 | |
| 20-01-2014 08:27 | zed | Note Added: 0013651 | |
| 27-01-2014 16:29 | zed | Note Added: 0013689 | |
| 27-01-2014 16:29 | zed | Status | new => feedback |
| 29-01-2014 16:34 | zed | Note Added: 0013696 | |
| 29-01-2014 16:38 | zed | Target Version | => 140303 |
| 29-01-2014 16:38 | zed | Status | feedback => resolved |
| 29-01-2014 16:38 | zed | Fixed in Version | => 140303 |
| 29-01-2014 16:38 | zed | Resolution | open => fixed |
| 29-01-2014 16:38 | zed | Assigned To | => zed |
| 29-01-2014 19:04 | vdemidov | Note Added: 0013697 | |
| 08-08-2025 13:22 | zed | Category | Баг => Баг / Bug |