View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0001103SAS.Планета[All Projects] Багpublic11-01-2012 07:3010-10-2012 11:47
ReporterTolik 
Assigned Tovdemidov 
PriorityhighSeveritymajorReproducibilitysometimes
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version.Nightly 
Target Version120808Fixed in Version120808 
Summary0001103: Останавливается скачивание тайлов для вывода на экран
DescriptionПосле достаточно длительного брожения по карте в разных направлениях и на разных зумах скачивание тайлов останавливается.
Проблема не в бане, SAS.Планета перестаёт слать запросы GET.
Вручную (например, Ins+Click) тайл скачивается нормально.
Режим установлен "Интернет". Переключение режимов не помогает. Включение-выключение карты (слоя) не помогает. Другие карты (слои) при этом работают нормально.
Помогает только перезапуск программы.

Наблюдается в ночных сборках достаточно давно. Сейчас версия 4775.
Когда проблема появилась - трудно сказать. Может быть, с появлением мультизагрузки?
Steps To ReproduceСегодня лазил часа 3 (не непрерывно, полазил - поработал :), включены были в основном спутник Nokia Map Creator + слой НЯК, НЯК работать перестал.
Additional InformationПока не перезапустил, если у кого-то есть идеи, что ещё можно проверить - жду.
Tagsзакачка, скачка
Attached Files? file icon SASPlanet.Debug.elf [^] (36,883 bytes) 16-02-2012 05:06
rar file icon ALWininetHttpClient.rar [^] (10,969 bytes) 25-02-2012 18:14
png file icon 2012-02-26_073757.png [^] (30,647 bytes) 26-02-2012 03:39

- Relationships
related to 0001190closedvdemidov Неправильно отрабатываются run time errors в паскальскрипте 
related to 0002301resolvedzed Залипания во время просмотра карты 

-  Notes
(0004848)
Garl (manager)
11-01-2012 08:39

подтверждаю. (думал у меня проблемы с интернетом)
(0004850)
Tolik (manager)
11-01-2012 08:42

И я так думал, но перезапуск программы всегда помогал. А сегодня даже не поленился wireshark запустить. Тайлы осн. карты САС запрашивает, а тайлы слоя нет.
(0004851)
zed (manager)
11-01-2012 08:45

И у меня такое периодически бывает.
(0004853)
Tolik (manager)
11-01-2012 08:48

Что-нибудь посоветуете подёргать, чтобы найти причину?
(0004854)
zed (manager)
11-01-2012 08:52

Запустить под отладчиком и смотреть в код. Или просто смотреть в код до просветления. Где-то окопался хитрый БАГ, который не выкидывает эксепшенов...
(0004864)
vasketsov (manager)
11-01-2012 13:23
edited on: 11-01-2012 13:28

Может быть связано.
Периодически (раз в несколько часов) в
function TALWinInetHTTPClient.Send(const aRequestDataStream: TStream): Integer;
на вход прилетат параметр NIL.
Далее AV с адресом 0x00000009 в wininet.
Наружу exception не вылетает.
Это нормально, или надо фиксить, чтобы NIL не залетал, или внутри по NIL просто валить из процы и всё? Хотя напрямую с NIL прохоже и не связано.
зы. возможно сабжевый баг связан с использованием ALWinInet, оно же тоже относительно недавно появилось.

(0004865)
zed (manager)
11-01-2012 13:45

Если бы переставало качать вообще, то да, а так походу до этого компонента вообще дело не доходит.
(0004866)
vdemidov (manager)
11-01-2012 13:51

А может просто вылетает тред с ексепшеном необработанным? А ексепшены в неосновном треде просто гасятся.
(0004867)
vasketsov (manager)
11-01-2012 14:30

>вылетает тред
скачка продолжает качаться после этого.
(0004869)
vdemidov (manager)
11-01-2012 14:49

Ну так для каждой карты создается отдельный тред, который ставит задания на закачку тайлов из отображаемой области. Вот он похоже и вылетает. А закачка по региону запускает свой тред, ставящий задания.
(0004870)
vasketsov (manager)
11-01-2012 15:28
edited on: 11-01-2012 15:44

в моём случае чётко видно, что баг был в локальной скачке с loopback (там выше по стеку адрес виден в параметрах), гуй саса у меня с него не качает, так что вылет полока привёл бы к остановке скачки, если только поток не был запущен снова каким-то спецмеханизмом (правда я скорее поверю в то, что AV просто был придушен).
впрочем наверное это не имеет отношения к сабжевой проблеме.
upd:
а может и имеет. обработка эксепшена в TALWinInetHTTPClient.Execute приводит к дисконнекту. выделенный поток перезапускается (что я и вижу в логе прокси, периодически дисконнект-конект). а гуёвый тред может просто не перезапускаться.

(0005331)
Tolik (manager)
04-02-2012 15:45
edited on: 04-02-2012 15:46

Похоже, есть прямая зависимость проблемы от числа ошибок от сервера.

Например, при тестировании недоделанных zmp (когда ошибка приходит на каждый тайл) это происходит очень быстро.
При работе через глюкавый прокси-сервер (когда ошибки происходят иногда) это происходит через пару часов.
Если ошибок нет, не происходит вообще.

Может быть, есть счётчик ошибок, который переполняется? Или утечка памяти при каждой ошибке? Возможно, связано с багом про слой ошибок 0001152?

(0005340)
vdemidov (manager)
05-02-2012 16:26

Не должно быть. Слой ошибок и качалка тайлов не взаимодействуют напрямую. Конечно может быть дело в логгере, который собирает инфу об ошибках. Нужно будет проверить.
(0005342)
Tolik (manager)
05-02-2012 17:00

Таки есть какой-то логгер ошибок. А как посмотреть этот лог?
(0005350)
vdemidov (manager)
05-02-2012 19:49

Никак. Потому что текущая реализация сохраняет только последнее событие, отображением которого и занимается слой отображения ошибок.
(0005353)
Tolik (manager)
06-02-2012 04:32

А жаль. Надо их (опционально) писать в файл.
Очень трудно отлавливать эти ошибки по экрану, как тараканов, да ещё гадать, что эти три буквы значат.
(0005474)
vdemidov (manager)
14-02-2012 21:25

Проверьте последнюю ночнушку. Я поправил несколько мест, которые с очень малой, но ненулевой вероятностью могли вызывать AV внутри качалки.
(0005485)
Tolik (manager)
15-02-2012 07:19
edited on: 15-02-2012 07:26

Не помогло.
Воспроизводится легко.
Взял карту maps.by, полазил с минуту там, где ошибка 400, качаться (для вывода на экран) перестало. Причём и ins+click не помогает! После перезапуска качается без проблем.

(0005495)
vdemidov (manager)
15-02-2012 11:54

Еще расставил критических секций. Проверяйте завтра.
(0005496)
Tolik (manager)
15-02-2012 12:04

Что такое критическая секция? Проверка на зависание?
(0005497)
vdemidov (manager)
15-02-2012 12:59

Нет. Это блокировка одновременного доступа из разных тредов.
(0005515)
Tolik (manager)
16-02-2012 05:03
edited on: 16-02-2012 05:06

Уж не знаю, с критическими секциями связано или нет...
САС жрёт до 60% CPU на довольно мощном компе при простом скролле (не важно, с картой из кэша или с пустым экраном и ошибками 400).
После того же упражнения - минутного брожения по пустой карте - и открывания окна меток выходит окошко AV, да не одно, а множество, закрыть их невозможно, надо мочить процесс.
Видел это уже 2жды, постараюсь добыть elf.

(0005516)
Tolik (manager)
16-02-2012 05:05

Elf раздобылся при первом же попадании на ошибку 400, прикладываю.
(0005517)
Garl (manager)
16-02-2012 05:05

ага . проц жрёт нещадно
(0005518)
Tolik (manager)
16-02-2012 05:26
edited on: 16-02-2012 05:27

Также не работает качалка. Выделяешь область, она сразу говорит task is completed

P.S. и сабжевая проблема не решена.

(0005602)
vasketsov (manager)
24-02-2012 08:12
edited on: 24-02-2012 08:31

Что-то совсем грустно (ничего в репо не заливал, просто поигрался малёхо):

1. TDownloaderHttpWithTTL.OnTTLTrim прилетает периодически, даже если "скачка" идёт как из пулемёта по 5 тайлов в секунду (под скачкой по тестируемой области я понимаю ответы 404, там новых тайлов для скачки уже нету). Обернул обращения к FDownloader в TMultiReadExclusiveWriteSynchronizer (DoRequest как Read, остальное как Write под if (not)assigned then) - вроде толку не дало, мало ли при отладке "задержки" могли быть.

2. При очистке заголовков (FHttpClient.RequestHeader.Clear в TDownloaderHttp.PreConfigHttpClient) гарантированно испускается Disconnect (внутри Clear зовётся DoChange(-1) в самом конце). Перекрыл в потомке procedure OnRequestHeaderChange(sender: Tobject; Const PropertyIndex: Integer); override - просто полностью придушил - как бы дисконнектов на прокси стало меньше. Но невозможность очистки заголовков без дисконнекта нещадно доставляет. Либу конечно надо пописать.

(0005603)
zed (manager)
24-02-2012 11:44

>При очистке заголовков (FHttpClient.RequestHeader.Clear в TDownloaderHttp.PreConfigHttpClient) гарантированно испускается Disconnect
Не понял, ведь Keep-Alive работал нормально. Правда, я через прокси не тестировал, но напрямую всё было ОК, без дисконнектов.
(0005604)
vasketsov (manager)
24-02-2012 12:04
edited on: 24-02-2012 12:05

>Не понял, ведь Keep-Alive работал нормально
А ты просто код либы погляди ))) Keep-Alive ни при чём.

>я через прокси не тестировал
Я работаю не через прокси. У меня в zmp написан урл типа http://127.0.0.1:9876, но там скрипт всё сам отдаёт, я его немного нечестно проксёй назвал, скорее это веб-сервер тогда уж, который только на bing работает.

Есть ещё идея, с точки зрения простого взгляда на код вероятность её реализации 99%. Смысл в игнорировании Connection closed gracefully.
Дело в том, что если взглянуть на TALWinInetHTTPClient, то в нём FConnected меняется только внутри тех мест, которые зовутся руками. И OnStatusChange никто не зовёт (ALWininetHTTPCLientStatusCallback везде закомментирована). Соответственно клиент знать не знает про то что сервер отрубился. Даже с указанием keep-alive клиент от Indy (который у меня росреестр качает без прокси часами один район - то есть долго) периодически ловит grace off, а тут либа вообще это не нюхает.

(0005605)
zed (manager)
24-02-2012 12:11

ХЗ, может и либа глючит, но до того, как vdemidov переписал качалку оно таких багов не ловило, хоть и работало на том же alcinoe.
(0005606)
zed (manager)
24-02-2012 12:50

>Смысл в игнорировании Connection closed gracefully
Да, но чуть выше ты же сам написал, что мы дисконнектимся перед каждым запросом (по Headers.Clear). Значит бага явно не отсюда, хотя, конечно игнорирование grace off не есть гуд и глюко-потенциально.
(0005607)
vasketsov (manager)
24-02-2012 13:35

>ты же сам написал, что мы дисконнектимся перед каждым запросом
разве? походу и заголовки не каждый раз пишутся, потому что бывает долго без дисконнекта работает.
(0005608)
zed (manager)
24-02-2012 14:19

>походу и заголовки не каждый раз пишутся
О, а вот тут надо будет посмотреть поподробнее. Когда я там последний раз ковырял, оно их каждый раз перезаписывало. Их возможно и не нужно каждый раз перезаписывать, но надо контролировать, что пользователь не поменял их в процессе загрузки.
В любом случае, метод PreConfigHttpClient должен вызываться каждый раз перед запросом.
(0005609)
zed (manager)
24-02-2012 17:19

Поправил:
1. Установка заголовков и настроек прокси, только если это действительно нужно, т.е. по-хорошему, disconnect вызываться вообще не должен. Но как я уже писал где-то тут, что если у нас в zmp прописано более одного хоста (тот же гугл мапс с его khm1,khm2 и т.д.), и поскольку потоки выбираются случайным образом (первый свободный), то у нас получается лишний дисконнект когда мы заставляем поток пере-подключаться к другому "родственному" хосту. Видимо, этот момент таки стоит вынести в отдельный тикет и как-нибудь пофиксить?
2. Подкрутил TTL и интервал проверки, так что в OnTTLTrim должны прилетать только через 5 минут простоя качалки.
(0005610)
zed (manager)
24-02-2012 18:06

>так что в OnTTLTrim должны прилетать только через 5 минут простоя качалки
Ха, а вот фиг. Прилетает через 5 минут в любом случае!
(0005612)
Tolik (manager)
25-02-2012 05:15

> если у нас в zmp прописано более одного хоста... получается лишний дисконнект

Если из-за этого возникают проблемы, может быть, проще прописать в zmp всего один?
Есть ли какая-то польза в прописывании нескольких? Например, гугл банит реже или точно так же?
(0005617)
zed (manager)
25-02-2012 06:39

>проще прописать в zmp всего один
Проще, но баг от этого никуда не денется и в долгосрочной перспективе может вылезти боком.
(0005620)
Tolik (manager)
25-02-2012 06:55

В сегодняшней ночнушке проблема не решена. Достаточно побродить несколько секунд там, где ошибка 400, и скачивание останавливается. Счётчик Queue показывает 0.
(0005628)
vasketsov (manager)
25-02-2012 12:58
edited on: 25-02-2012 12:59

Я допёр в чём беда. Точнее их там даже две беды. Ща разберусь как OnTTLTrim работает, и нагажу в репо.
зы. А всё поому что сегодня бага начала у меня воспроизводиться именно в виде переставания качания, раньше только множественные коннекты и дисконнекты фиксировал.

(0005629)
vasketsov (manager)
25-02-2012 15:45

Вощем нифига не пойму как OnTTLTrim работает, работает как попало, поток не качает - а OnTTLTrim не приходит.
А без его лечения очевидно проблему не решить, ибо других "пингов" не предусмотрено. Вощем лечите для начала OnTTLTrim, кто понимает как оно должно работать.

Обе беды с инетом решаются так (_для_разработчикоффф_):

1. Надо раскомментировать ALWininetHTTPCLientStatusCallback и установить внутри TDownloaderHttp.Create обработчик события FHttpClient.OnStatusChange, в котором ловить 3 "события" (по значению InternetStatus): INTERNET_STATUS_HANDLE_CREATED и пару INTERNET_STATUS_CLOSING_CONNECTION и INTERNET_STATUS_CONNECTION_CLOSED.

2. Два вторых надо обрабатывать, если они наступили не внутри вызова Disconnect. Соответственно их приход и означает, что сервер послал нас на несколько весёлых букв. Надо вызвать Disconnect. Но делать это напрямую нельзя, в обработчике только надо поднять флаг, который потом понюхать (достаточно внутри DoRequest, чтобы вызвать Disconnect сразу после захвата критической секции). Так обрабатывается разрыв соединения.

3. Обработка INTERNET_STATUS_HANDLE_CREATED более сложная. Там приходит хэндл с созданным HINTERNET, вызов испускается изнутри InternetConnect до возвращения из этой функции. Если вызов внутри InternetConnect слишком долго задерживается - надо его просто грохнуть вызовом InternetCloseHandle. Соответственно надо сохранить хэндл, на который ссылается pointer в обработчике, и просто проверить в OnTTLTrim, как давно вызывалась FDownloader.DoRequest (если InternetConnect зависает - то FDownloader.DoRequest не завершается, соответственно критическая секция не освобождается - поэтому внутри OnTTLTrim проверку на зависание InternetConnect надо делать до захвата критической секции). И если OnTTLTrim будет работать только на проверку зависания InternetConnect (а она возникает даже при URL типа loopback), то этот вызов должен вызываться сильно чаще, скажем раз в 10 секунд.

Залью часть, которая отсекает disconnect (это u_DownloaderHttp и ALWininetHttpClient). Часть, которая грохает зависший InternetConnect, сейчас напрочь бессмысленна (пока OnTTLTrim не вылечен).
(0005630)
zed (manager)
25-02-2012 17:00

Т.е. из-за исключения в компоненте, в САС вылетал поток? Или что? Оно же там вроде обёрнуто в try - except и должна была быть нормальная обработка ошибок без райзов наружу.
(0005631)
vasketsov (manager)
25-02-2012 17:14
edited on: 25-02-2012 17:52

>из-за исключения в компоненте, в САС вылетал поток?
Нет, никаких исключений, всё тихо.

>должна была быть нормальная обработка ошибок
Дело в том, что сервер закрывает соединение когда закончил работу, greacefully closed не является ошибкой, но должно обрабатываться. Например, в Indy кидается специальное исключение. А тут нифига, так как инфа об этом приходит только в обработчик, который не установлен.

ps. Надо раскомментировать всё что касается ALWininetHTTPCLientStatusCallback в файле ALWininetHttpClient, я не понял как это правильно сделать в requires.

(0005632)
zed (manager)
25-02-2012 18:03
edited on: 25-02-2012 18:06

В смысле, как это закоммитить? Скорее всего только через Клон + Пул-Реквест. Если лень, кинься изменённым файлом, я сам залью.
Хотя, по-идее у тебя должен быть доступ на запись к https://bitbucket.org/zedxxx/alcinoe

(0005633)
vasketsov (manager)
25-02-2012 18:16

Приаттачил. Предлагаю собрать сегодня ночнуху c этой правкой, и соответственно "штатный бетатестер" может быть даже выскажет своё "фи" завтра. А то у меня опять после перезагрузки виндеца перестало воспроизводиться (LOL).
(0005634)
zed (manager)
25-02-2012 18:33

>Предлагаю собрать сегодня ночнуху c этой правкой
Обязательно.
(0005639)
vdemidov (manager)
25-02-2012 20:46

Насчет OnTTLTrim. Там есть глупость, что если простаивает, то он вызывается каждый раз. Я это завтра пофикшу. А вот причин что бы вызвался OnTTLTrim если качалка юзается я не вижу. Смотреть нужно в u_TTLCheckListener.
(0005641)
vasketsov (manager)
25-02-2012 20:51

>А вот причин что бы вызвался OnTTLTrim если качалка юзается я не вижу
там возможно другая беда, что обработчик TTL устанавливается ДО фактчиеского создания качалки, и может быть поэтому он и прилетал, глядет на пустой интерфейс, в 100500-й раз присваивал ему NIL и дальше летел по делам.
Как то бы связать факт создания\смерти качалки и факт установки\удаления обработки TTL.

Там более актуальна другая беда. На одной карте качает интерфейс (пеемещением о карте) + один поток. Поток блокируется и останавливается - и для него не приходит TTL. Возможно потому что по этой же карте качает интерфейс, а может ещё по каким причинам.
(0005642)
vdemidov (manager)
25-02-2012 21:00

> Как то бы связать факт создания\смерти качалки и факт установки\удаления обработки TTL.
Зачем? Нужно просто, что бы OnTTLTrim не вызывался, если не было вызова UpdateUseTime.

>Там более актуальна другая беда. На одной карте качает интерфейс (пеемещением о карте) + один поток. Поток блокируется и останавливается - и для него не приходит TTL. Возможно потому что по этой же карте качает интерфейс, а может ещё по каким причинам.

Ничего не понял.
(0005646)
Tolik (manager)
26-02-2012 03:27

"фи". В смысле, увы :(
Как я уже писал много раз, воспроизводится мгновенно, достаточно словить всего лишь с десяток ошибок 400.

Объясните мне, _не_разрабоччику_, что конкретно отвисает в программе после именно этой ошибки? Может, сбилдите дебажную версию, которая по этой ошибке будет писать в лог всё, что происходит (стек трейсы и т.п.)?

Да и простой лог 0001159 мог бы помочь.
(0005647)
Tolik (manager)
26-02-2012 03:38
edited on: 26-02-2012 03:41

Точнее, всего 4 (четыре!) ошибки 400.
Если учесть, что MaxConnectToServerCount=4, качалка отвисает после одной-единственной ошибки. См. 2012-02-26_073757.png

(0005650)
zed (manager)
26-02-2012 06:15

Приаттачте-ка свой zmp?
(0005651)
Tolik (manager)
26-02-2012 06:22

Да вот он: maps.by http://sasgis.org/forum/viewtopic.php?p=25943#p25943
Ошибка 400 возникает, например, если перейти на зум 6. И вообще, zmp недоделан, работает не вся карта.
(0005652)
vasketsov (manager)
26-02-2012 08:31

>что конкретно отвисает в программе после именно этой ошибки?
Если конкретно про то что я исправил - это обработка разрыва соединения со стороны сервера, раньше она не обрабатывалась, и поток по-прежнему думал, что есть коннект. В этом случае при последующих запросах внутри DLL вылетал AV с адресом 0x00000009 (как правило), ну а дальше очевидно всё что угодно. Это то что воспроизводилось у меня до вчерашнего дня.

>воспроизводится мгновенно
А вот у меня как раз с этим "беда", сегодня ещё не пробовал, но пока что воспроизводится "зависание" потока у меня крайне редко, почти никогда.
Это зависание потенциально возможно по двум причинам. Первая - в поток вообще не приходит запрос, где-то блокируется и чего-то ждёт, тогда это проблема саса. Вторая - это зависания при подключении - штатная ситуация, обход которой простой, но требует чёткой работы специальной сасовской процедуры OnTTLTrim (чтобы в ней проверять зависание внутри InternetConnect). Это я не заливал, ибо это полумера и не работало бы без OnTTLTrim (я там оставил закомментированные куски, их надо будет раскомментировать и добавить проверку на InternetConnect).

Если зависание начинается после нескольких секунд работы - это вторая беда, connection closed gracefully тут ни при чем. То что я пофиксил - это ошибки скачки одного рабочего потока после как правило довольно продолжительной скачки (остановка, AV и т.п.), см. 6-й комментарий в этой теме и мой первый.
(0005653)
vasketsov (manager)
26-02-2012 08:44

>Ничего не понял
0. Вправил TTL для качалки в 10 секунд.
1. Выбирал bing на 18-м зуме в режиме "только кэш".
2. Запускал скачку bing-а по выделенной области в 4 тыщи тайлов на бинге на 15-м зуме, где тайлов для скачки уже нет (соответственно ЭТОТ поток ловит только HTTP 404, даже не 400).
3. Поток качал только tne, но работал и не говорил, что нет подключения.
4. Включил режим "инет+кэш", сдвинул карту.
5. Внизу Queue выросло до ненулевых значений, интерфейсные потоки качали тайлы 18-го зума бинга....
6. ... но при этом первоначальный поток встал.
7. Поставил бряк на OnTTLTrim - нифига (ну только для "пустых" приходит, для которых не вызывалось ни одного запроса, и не создан внутренний интерфейс качалки). Хотя первоначальный поток не качал уже долго. Потом он выдал "отсутствует подключение", штатно помер и запустился заново.
8. После всех этих сдвигов карты при параллельном качании осталось постоянно висеть в статусбаре минимальное значение Queue 1, а не 0 - явно "внутри" завис поток.
(0005654)
zed (manager)
26-02-2012 08:46

Если счётчик очереди в статус строке (Queue) равен нулю, то видимо, проблема в TUiTileDownload (т.к. именно он инкрементит этот счётчик).
(0005655)
vasketsov (manager)
26-02-2012 08:56
edited on: 26-02-2012 08:56

>видимо, проблема в TUiTileDownload
Я при похожих зависаниях (срочно вырубал интерфейсные потоки отключением режима интернета) ставил бряк на InternetConnect и следующую строку, а также в даунлоадере на DoRequest и следующую строку. В обоих случаях выполнение останавливалось на втором бряке - то есть мы висели внутри InternetConnect и DoRequest соответственно - и по Disconnect оттуда радостно вылетали. Понятно, что это были два конкретных зависания, в других случаях может быть и другое.

(0005658)
zed (manager)
26-02-2012 12:14
edited on: 26-02-2012 12:15

>Ошибка 400 возникает, например, если перейти на зум 6. И вообще, zmp недоделан, работает не вся карта.
Так, давайте разбираться. Карта работает только для зумов 10..20, о чём сделано предупреждение (вами же). У меня при попытке выхода за эти границы вываливается ошибка паскаль-скрипта (TypeMismatch). Так что может ошибка и не в качалке вовсе. На зумах 10..20 проблемы с закачкой наблюдаются?
Далее, да удалось словить 400-х ошибок и много, но качалка работала исправно (на зумах 10..20). Единственное, пару раз прилетели ошибки от качалки (Exception class EqhValidation with message 'qhMap.VariantToHash: parameter "Key" is of an unsupported type (type code 3596)') из-за того, что в TALWinInetHTTPClient.Execute приходит aRequestDataStream=nil (vasketsov ранее про эту ошибку так же упоминал). Но качалка из-за этого не падает, и всё продолжает работать в штатном режиме.

Так что нужно расширенное описание для воспроизведения бага. Может первоначальный баг уже помер, а мы и не знаем?

(0005660)
Tolik (manager)
26-02-2012 13:19

> У меня при попытке выхода за эти границы вываливается ошибка паскаль-скрипта (TypeMismatch).
Интересно, почему у меня эта ошибка не вываливается?
Вообще-то логично: там массив не определён для этого зума. Я раньше об этом не подумал. Так паскаль-скрипт из-за этого тихо умирает?
Именно тихо, даже в параметрах карты показывает download state=yes. Но при переходе на правильный зум качать не начинает. Видимо, надо открыть другой баг-репорт про это?


На зуме, например, 17, если выйти далеко за пределы карты, тоже возникает ошибка 400. Она прям сразу не убивает качалку. Позже потестирую подольше, т.к. первоначально ошибка проявлялась не сразу.
(0005662)
zed (manager)
26-02-2012 13:24

>Интересно, почему у меня эта ошибка не вываливается?
Потому что я под отладчиком это всё смотрел. Даже debug версия об обработанных ошибках не сообщает. Видимо где-то она там далее по коду тихо подавляется.

>надо открыть другой баг-репорт про это?
Да.
(0005682)
vdemidov (manager)
27-02-2012 15:53

Итого проверяем после всех исправлений. Есть бага?
(0005694)
Tolik (manager)
28-02-2012 06:50

Вчера не зависала!
Сегодня хорошо проверить не могу, давайте ещё несколько дней погоняем.
(0005711)
vdemidov (manager)
28-02-2012 11:36

Ждем
(0005778)
Tolik (manager)
02-03-2012 09:52
edited on: 02-03-2012 10:10

Вроде больше не зависает! Хотя и не было времени специально гонять туда-сюда.

Вот только стала очень сильно грузить проц. при скролле.
Если нажать кнопку со стрелкой, карта движется медленно, с жуткими рывками, загрузка проц. повышается чуть ли не до 100%.
Это связано с новыми критическими секциями?

P.S. Например, версия 4891 движется заметно быстрее и более плавно, чем последняя (5140), проц. тоже загружается сильно, но не настолько.
А бета вообще летает, и загрузка проц. около нуля.
Такое ощущение, что каждая следующая версия тормозит всё сильнее :(


- Users who viewed this issue
User List Anonymous (3324x)
Total Views 3324
Last View 05-04-2020 01:02

- Issue History
Date Modified Username Field Change
11-01-2012 07:30 Tolik New Issue
11-01-2012 07:30 Tolik Priority normal => high
11-01-2012 07:30 Tolik Severity minor => major
11-01-2012 07:30 Tolik Status new => acknowledged
11-01-2012 07:30 Tolik Summary Останавливается скачивание тайлов для ваывода на экран => Останавливается скачивание тайлов для вывода на экран
11-01-2012 08:39 Garl Note Added: 0004848
11-01-2012 08:41 Tolik Description Updated View Revisions
11-01-2012 08:42 Tolik Note Added: 0004850
11-01-2012 08:45 zed Note Added: 0004851
11-01-2012 08:48 Tolik Note Added: 0004853
11-01-2012 08:52 zed Note Added: 0004854
11-01-2012 13:23 vasketsov Note Added: 0004864
11-01-2012 13:24 vasketsov Note Edited: 0004864 View Revisions
11-01-2012 13:28 vasketsov Note Edited: 0004864 View Revisions
11-01-2012 13:45 zed Note Added: 0004865
11-01-2012 13:51 vdemidov Note Added: 0004866
11-01-2012 14:30 vasketsov Note Added: 0004867
11-01-2012 14:49 vdemidov Note Added: 0004869
11-01-2012 15:28 vasketsov Note Added: 0004870
11-01-2012 15:44 vasketsov Note Edited: 0004870 View Revisions
11-01-2012 20:06 gpsMax Tag Attached: закачка
11-01-2012 20:06 gpsMax Tag Attached: скачка
27-01-2012 21:32 vdemidov Status acknowledged => confirmed
27-01-2012 21:32 vdemidov Target Version => 120808
04-02-2012 15:45 Tolik Note Added: 0005331
04-02-2012 15:46 Tolik Note Edited: 0005331 View Revisions
05-02-2012 16:26 vdemidov Note Added: 0005340
05-02-2012 17:00 Tolik Note Added: 0005342
05-02-2012 19:49 vdemidov Note Added: 0005350
06-02-2012 04:32 Tolik Note Added: 0005353
14-02-2012 21:25 vdemidov Note Added: 0005474
14-02-2012 21:25 vdemidov Status confirmed => feedback
15-02-2012 07:19 Tolik Note Added: 0005485
15-02-2012 07:19 Tolik Status feedback => new
15-02-2012 07:20 Tolik Assigned To => vdemidov
15-02-2012 07:20 Tolik Status new => confirmed
15-02-2012 07:26 Tolik Note Edited: 0005485 View Revisions
15-02-2012 11:54 vdemidov Note Added: 0005495
15-02-2012 11:54 vdemidov Status confirmed => feedback
15-02-2012 12:04 Tolik Note Added: 0005496
15-02-2012 12:04 Tolik Status feedback => assigned
15-02-2012 12:59 vdemidov Note Added: 0005497
16-02-2012 05:03 Tolik Note Added: 0005515
16-02-2012 05:05 Tolik Note Added: 0005516
16-02-2012 05:05 Garl Note Added: 0005517
16-02-2012 05:06 Tolik File Added: SASPlanet.Debug.elf
16-02-2012 05:06 Tolik Note Edited: 0005515 View Revisions
16-02-2012 05:26 Tolik Note Added: 0005518
16-02-2012 05:27 Tolik Note Edited: 0005518 View Revisions
24-02-2012 08:12 vasketsov Note Added: 0005602
24-02-2012 08:31 vasketsov Note Edited: 0005602 View Revisions
24-02-2012 11:44 zed Note Added: 0005603
24-02-2012 12:04 vasketsov Note Added: 0005604
24-02-2012 12:05 vasketsov Note Edited: 0005604 View Revisions
24-02-2012 12:11 zed Note Added: 0005605
24-02-2012 12:50 zed Note Added: 0005606
24-02-2012 13:35 vasketsov Note Added: 0005607
24-02-2012 14:19 zed Note Added: 0005608
24-02-2012 17:19 zed Note Added: 0005609
24-02-2012 18:06 zed Note Added: 0005610
25-02-2012 05:15 Tolik Note Added: 0005612
25-02-2012 06:39 zed Note Added: 0005617
25-02-2012 06:55 Tolik Note Added: 0005620
25-02-2012 12:58 vasketsov Note Added: 0005628
25-02-2012 12:59 vasketsov Note Edited: 0005628 View Revisions
25-02-2012 15:45 vasketsov Note Added: 0005629
25-02-2012 17:00 zed Note Added: 0005630
25-02-2012 17:14 vasketsov Note Added: 0005631
25-02-2012 17:52 vasketsov Note Edited: 0005631 View Revisions
25-02-2012 18:03 zed Note Added: 0005632
25-02-2012 18:06 zed Note Edited: 0005632 View Revisions
25-02-2012 18:14 vasketsov File Added: ALWininetHttpClient.rar
25-02-2012 18:16 vasketsov Note Added: 0005633
25-02-2012 18:33 zed Note Added: 0005634
25-02-2012 20:46 vdemidov Note Added: 0005639
25-02-2012 20:51 vasketsov Note Added: 0005641
25-02-2012 21:00 vdemidov Note Added: 0005642
26-02-2012 03:27 Tolik Note Added: 0005646
26-02-2012 03:38 Tolik Note Added: 0005647
26-02-2012 03:39 Tolik File Added: 2012-02-26_073757.png
26-02-2012 03:41 Tolik Note Edited: 0005647 View Revisions
26-02-2012 06:15 zed Note Added: 0005650
26-02-2012 06:22 Tolik Note Added: 0005651
26-02-2012 08:31 vasketsov Note Added: 0005652
26-02-2012 08:44 vasketsov Note Added: 0005653
26-02-2012 08:46 zed Note Added: 0005654
26-02-2012 08:56 vasketsov Note Added: 0005655
26-02-2012 08:56 vasketsov Note Edited: 0005655 View Revisions
26-02-2012 12:14 zed Note Added: 0005658
26-02-2012 12:15 zed Note Edited: 0005658 View Revisions
26-02-2012 13:19 Tolik Note Added: 0005660
26-02-2012 13:24 zed Note Added: 0005662
26-02-2012 13:24 Tolik Note Added: 0005663
26-02-2012 13:25 Tolik Note Edited: 0005663 View Revisions
27-02-2012 04:44 Tolik Note Deleted: 0005663
27-02-2012 04:44 Tolik Relationship added related to 0001190
27-02-2012 15:53 vdemidov Note Added: 0005682
27-02-2012 15:53 vdemidov Status assigned => feedback
28-02-2012 06:50 Tolik Note Added: 0005694
28-02-2012 06:50 Tolik Status feedback => assigned
28-02-2012 11:36 vdemidov Note Added: 0005711
28-02-2012 11:36 vdemidov Status assigned => feedback
02-03-2012 09:52 Tolik Note Added: 0005778
02-03-2012 09:52 Tolik Status feedback => assigned
02-03-2012 09:52 Tolik Status assigned => resolved
02-03-2012 09:52 Tolik Fixed in Version => 120808
02-03-2012 09:52 Tolik Resolution open => fixed
02-03-2012 10:09 Tolik Note Edited: 0005778 View Revisions
02-03-2012 10:10 Tolik Note Edited: 0005778 View Revisions
10-10-2012 11:47 Tolik Status resolved => closed
29-12-2013 11:05 zed Relationship added related to 0002301



Copyright © 2007 - 2020 SAS.Planet Team