|
Notes |
|
|
(0004848)
|
|
Garl
|
|
11-01-2012 08:39
|
|
|
подтверждаю. (думал у меня проблемы с интернетом) |
|
|
|
(0004850)
|
|
Tolik
|
|
11-01-2012 08:42
|
|
|
И я так думал, но перезапуск программы всегда помогал. А сегодня даже не поленился wireshark запустить. Тайлы осн. карты САС запрашивает, а тайлы слоя нет. |
|
|
|
(0004851)
|
|
zed
|
|
11-01-2012 08:45
|
|
|
И у меня такое периодически бывает. |
|
|
|
(0004853)
|
|
Tolik
|
|
11-01-2012 08:48
|
|
|
Что-нибудь посоветуете подёргать, чтобы найти причину? |
|
|
|
(0004854)
|
|
zed
|
|
11-01-2012 08:52
|
|
|
Запустить под отладчиком и смотреть в код. Или просто смотреть в код до просветления. Где-то окопался хитрый БАГ, который не выкидывает эксепшенов... |
|
|
|
(0004864)
|
|
vasketsov
|
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
|
|
11-01-2012 13:45
|
|
|
Если бы переставало качать вообще, то да, а так походу до этого компонента вообще дело не доходит. |
|
|
|
|
|
А может просто вылетает тред с ексепшеном необработанным? А ексепшены в неосновном треде просто гасятся. |
|
|
|
|
>вылетает тред
скачка продолжает качаться после этого. |
|
|
|
|
|
Ну так для каждой карты создается отдельный тред, который ставит задания на закачку тайлов из отображаемой области. Вот он похоже и вылетает. А закачка по региону запускает свой тред, ставящий задания. |
|
|
|
(0004870)
|
|
vasketsov
|
11-01-2012 15:28
(edited on: 11-01-2012 15:44) |
|
в моём случае чётко видно, что баг был в локальной скачке с loopback (там выше по стеку адрес виден в параметрах), гуй саса у меня с него не качает, так что вылет полока привёл бы к остановке скачки, если только поток не был запущен снова каким-то спецмеханизмом (правда я скорее поверю в то, что AV просто был придушен).
впрочем наверное это не имеет отношения к сабжевой проблеме.
upd:
а может и имеет. обработка эксепшена в TALWinInetHTTPClient.Execute приводит к дисконнекту. выделенный поток перезапускается (что я и вижу в логе прокси, периодически дисконнект-конект). а гуёвый тред может просто не перезапускаться.
|
|
|
|
(0005331)
|
|
Tolik
|
04-02-2012 15:45
(edited on: 04-02-2012 15:46) |
|
Похоже, есть прямая зависимость проблемы от числа ошибок от сервера.
Например, при тестировании недоделанных zmp (когда ошибка приходит на каждый тайл) это происходит очень быстро.
При работе через глюкавый прокси-сервер (когда ошибки происходят иногда) это происходит через пару часов.
Если ошибок нет, не происходит вообще.
Может быть, есть счётчик ошибок, который переполняется? Или утечка памяти при каждой ошибке? Возможно, связано с багом про слой ошибок 0001152?
|
|
|
|
|
|
Не должно быть. Слой ошибок и качалка тайлов не взаимодействуют напрямую. Конечно может быть дело в логгере, который собирает инфу об ошибках. Нужно будет проверить. |
|
|
|
(0005342)
|
|
Tolik
|
|
05-02-2012 17:00
|
|
|
Таки есть какой-то логгер ошибок. А как посмотреть этот лог? |
|
|
|
|
|
Никак. Потому что текущая реализация сохраняет только последнее событие, отображением которого и занимается слой отображения ошибок. |
|
|
|
(0005353)
|
|
Tolik
|
|
06-02-2012 04:32
|
|
А жаль. Надо их (опционально) писать в файл.
Очень трудно отлавливать эти ошибки по экрану, как тараканов, да ещё гадать, что эти три буквы значат. |
|
|
|
|
|
Проверьте последнюю ночнушку. Я поправил несколько мест, которые с очень малой, но ненулевой вероятностью могли вызывать AV внутри качалки. |
|
|
|
(0005485)
|
|
Tolik
|
15-02-2012 07:19
(edited on: 15-02-2012 07:26) |
|
Не помогло.
Воспроизводится легко.
Взял карту maps.by, полазил с минуту там, где ошибка 400, качаться (для вывода на экран) перестало. Причём и ins+click не помогает! После перезапуска качается без проблем.
|
|
|
|
|
|
Еще расставил критических секций. Проверяйте завтра. |
|
|
|
(0005496)
|
|
Tolik
|
|
15-02-2012 12:04
|
|
|
Что такое критическая секция? Проверка на зависание? |
|
|
|
|
|
Нет. Это блокировка одновременного доступа из разных тредов. |
|
|
|
(0005515)
|
|
Tolik
|
16-02-2012 05:03
(edited on: 16-02-2012 05:06) |
|
Уж не знаю, с критическими секциями связано или нет...
САС жрёт до 60% CPU на довольно мощном компе при простом скролле (не важно, с картой из кэша или с пустым экраном и ошибками 400).
После того же упражнения - минутного брожения по пустой карте - и открывания окна меток выходит окошко AV, да не одно, а множество, закрыть их невозможно, надо мочить процесс.
Видел это уже 2жды, постараюсь добыть elf.
|
|
|
|
(0005516)
|
|
Tolik
|
|
16-02-2012 05:05
|
|
|
Elf раздобылся при первом же попадании на ошибку 400, прикладываю. |
|
|
|
(0005517)
|
|
Garl
|
|
16-02-2012 05:05
|
|
|
|
|
(0005518)
|
|
Tolik
|
16-02-2012 05:26
(edited on: 16-02-2012 05:27) |
|
Также не работает качалка. Выделяешь область, она сразу говорит task is completed
P.S. и сабжевая проблема не решена.
|
|
|
|
(0005602)
|
|
vasketsov
|
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
|
|
24-02-2012 11:44
|
|
>При очистке заголовков (FHttpClient.RequestHeader.Clear в TDownloaderHttp.PreConfigHttpClient) гарантированно испускается Disconnect
Не понял, ведь Keep-Alive работал нормально. Правда, я через прокси не тестировал, но напрямую всё было ОК, без дисконнектов. |
|
|
|
(0005604)
|
|
vasketsov
|
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
|
|
24-02-2012 12:11
|
|
|
ХЗ, может и либа глючит, но до того, как vdemidov переписал качалку оно таких багов не ловило, хоть и работало на том же alcinoe. |
|
|
|
(0005606)
|
|
zed
|
|
24-02-2012 12:50
|
|
>Смысл в игнорировании Connection closed gracefully
Да, но чуть выше ты же сам написал, что мы дисконнектимся перед каждым запросом (по Headers.Clear). Значит бага явно не отсюда, хотя, конечно игнорирование grace off не есть гуд и глюко-потенциально. |
|
|
|
|
>ты же сам написал, что мы дисконнектимся перед каждым запросом
разве? походу и заголовки не каждый раз пишутся, потому что бывает долго без дисконнекта работает. |
|
|
|
(0005608)
|
|
zed
|
|
24-02-2012 14:19
|
|
>походу и заголовки не каждый раз пишутся
О, а вот тут надо будет посмотреть поподробнее. Когда я там последний раз ковырял, оно их каждый раз перезаписывало. Их возможно и не нужно каждый раз перезаписывать, но надо контролировать, что пользователь не поменял их в процессе загрузки.
В любом случае, метод PreConfigHttpClient должен вызываться каждый раз перед запросом. |
|
|
|
(0005609)
|
|
zed
|
|
24-02-2012 17:19
|
|
Поправил:
1. Установка заголовков и настроек прокси, только если это действительно нужно, т.е. по-хорошему, disconnect вызываться вообще не должен. Но как я уже писал где-то тут, что если у нас в zmp прописано более одного хоста (тот же гугл мапс с его khm1,khm2 и т.д.), и поскольку потоки выбираются случайным образом (первый свободный), то у нас получается лишний дисконнект когда мы заставляем поток пере-подключаться к другому "родственному" хосту. Видимо, этот момент таки стоит вынести в отдельный тикет и как-нибудь пофиксить?
2. Подкрутил TTL и интервал проверки, так что в OnTTLTrim должны прилетать только через 5 минут простоя качалки. |
|
|
|
(0005610)
|
|
zed
|
|
24-02-2012 18:06
|
|
>так что в OnTTLTrim должны прилетать только через 5 минут простоя качалки
Ха, а вот фиг. Прилетает через 5 минут в любом случае! |
|
|
|
(0005612)
|
|
Tolik
|
|
25-02-2012 05:15
|
|
> если у нас в zmp прописано более одного хоста... получается лишний дисконнект
Если из-за этого возникают проблемы, может быть, проще прописать в zmp всего один?
Есть ли какая-то польза в прописывании нескольких? Например, гугл банит реже или точно так же? |
|
|
|
(0005617)
|
|
zed
|
|
25-02-2012 06:39
|
|
>проще прописать в zmp всего один
Проще, но баг от этого никуда не денется и в долгосрочной перспективе может вылезти боком. |
|
|
|
(0005620)
|
|
Tolik
|
|
25-02-2012 06:55
|
|
|
В сегодняшней ночнушке проблема не решена. Достаточно побродить несколько секунд там, где ошибка 400, и скачивание останавливается. Счётчик Queue показывает 0. |
|
|
|
(0005628)
|
|
vasketsov
|
25-02-2012 12:58
(edited on: 25-02-2012 12:59) |
|
Я допёр в чём беда. Точнее их там даже две беды. Ща разберусь как OnTTLTrim работает, и нагажу в репо.
зы. А всё поому что сегодня бага начала у меня воспроизводиться именно в виде переставания качания, раньше только множественные коннекты и дисконнекты фиксировал.
|
|
|
|
|
Вощем нифига не пойму как 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
|
|
25-02-2012 17:00
|
|
|
Т.е. из-за исключения в компоненте, в САС вылетал поток? Или что? Оно же там вроде обёрнуто в try - except и должна была быть нормальная обработка ошибок без райзов наружу. |
|
|
|
(0005631)
|
|
vasketsov
|
25-02-2012 17:14
(edited on: 25-02-2012 17:52) |
|
>из-за исключения в компоненте, в САС вылетал поток?
Нет, никаких исключений, всё тихо.
>должна была быть нормальная обработка ошибок
Дело в том, что сервер закрывает соединение когда закончил работу, greacefully closed не является ошибкой, но должно обрабатываться. Например, в Indy кидается специальное исключение. А тут нифига, так как инфа об этом приходит только в обработчик, который не установлен.
ps. Надо раскомментировать всё что касается ALWininetHTTPCLientStatusCallback в файле ALWininetHttpClient, я не понял как это правильно сделать в requires.
|
|
|
|
(0005632)
|
|
zed
|
25-02-2012 18:03
(edited on: 25-02-2012 18:06) |
|
В смысле, как это закоммитить? Скорее всего только через Клон + Пул-Реквест. Если лень, кинься изменённым файлом, я сам залью.
Хотя, по-идее у тебя должен быть доступ на запись к https://bitbucket.org/zedxxx/alcinoe
|
|
|
|
|
|
Приаттачил. Предлагаю собрать сегодня ночнуху c этой правкой, и соответственно "штатный бетатестер" может быть даже выскажет своё "фи" завтра. А то у меня опять после перезагрузки виндеца перестало воспроизводиться (LOL). |
|
|
|
(0005634)
|
|
zed
|
|
25-02-2012 18:33
|
|
>Предлагаю собрать сегодня ночнуху c этой правкой
Обязательно. |
|
|
|
|
|
Насчет OnTTLTrim. Там есть глупость, что если простаивает, то он вызывается каждый раз. Я это завтра пофикшу. А вот причин что бы вызвался OnTTLTrim если качалка юзается я не вижу. Смотреть нужно в u_TTLCheckListener. |
|
|
|
|
>А вот причин что бы вызвался OnTTLTrim если качалка юзается я не вижу
там возможно другая беда, что обработчик TTL устанавливается ДО фактчиеского создания качалки, и может быть поэтому он и прилетал, глядет на пустой интерфейс, в 100500-й раз присваивал ему NIL и дальше летел по делам.
Как то бы связать факт создания\смерти качалки и факт установки\удаления обработки TTL.
Там более актуальна другая беда. На одной карте качает интерфейс (пеемещением о карте) + один поток. Поток блокируется и останавливается - и для него не приходит TTL. Возможно потому что по этой же карте качает интерфейс, а может ещё по каким причинам. |
|
|
|
|
> Как то бы связать факт создания\смерти качалки и факт установки\удаления обработки TTL.
Зачем? Нужно просто, что бы OnTTLTrim не вызывался, если не было вызова UpdateUseTime.
>Там более актуальна другая беда. На одной карте качает интерфейс (пеемещением о карте) + один поток. Поток блокируется и останавливается - и для него не приходит TTL. Возможно потому что по этой же карте качает интерфейс, а может ещё по каким причинам.
Ничего не понял. |
|
|
|
(0005646)
|
|
Tolik
|
|
26-02-2012 03:27
|
|
"фи". В смысле, увы :(
Как я уже писал много раз, воспроизводится мгновенно, достаточно словить всего лишь с десяток ошибок 400.
Объясните мне, _не_разрабоччику_, что конкретно отвисает в программе после именно этой ошибки? Может, сбилдите дебажную версию, которая по этой ошибке будет писать в лог всё, что происходит (стек трейсы и т.п.)?
Да и простой лог 0001159 мог бы помочь. |
|
|
|
(0005647)
|
|
Tolik
|
26-02-2012 03:38
(edited on: 26-02-2012 03:41) |
|
Точнее, всего 4 (четыре!) ошибки 400.
Если учесть, что MaxConnectToServerCount=4, качалка отвисает после одной-единственной ошибки. См. 2012-02-26_073757.png
|
|
|
|
(0005650)
|
|
zed
|
|
26-02-2012 06:15
|
|
|
|
|
(0005651)
|
|
Tolik
|
|
26-02-2012 06:22
|
|
Да вот он: maps.by http://sasgis.org/forum/viewtopic.php?p=25943#p25943
Ошибка 400 возникает, например, если перейти на зум 6. И вообще, zmp недоделан, работает не вся карта. |
|
|
|
|
>что конкретно отвисает в программе после именно этой ошибки?
Если конкретно про то что я исправил - это обработка разрыва соединения со стороны сервера, раньше она не обрабатывалась, и поток по-прежнему думал, что есть коннект. В этом случае при последующих запросах внутри DLL вылетал AV с адресом 0x00000009 (как правило), ну а дальше очевидно всё что угодно. Это то что воспроизводилось у меня до вчерашнего дня.
>воспроизводится мгновенно
А вот у меня как раз с этим "беда", сегодня ещё не пробовал, но пока что воспроизводится "зависание" потока у меня крайне редко, почти никогда.
Это зависание потенциально возможно по двум причинам. Первая - в поток вообще не приходит запрос, где-то блокируется и чего-то ждёт, тогда это проблема саса. Вторая - это зависания при подключении - штатная ситуация, обход которой простой, но требует чёткой работы специальной сасовской процедуры OnTTLTrim (чтобы в ней проверять зависание внутри InternetConnect). Это я не заливал, ибо это полумера и не работало бы без OnTTLTrim (я там оставил закомментированные куски, их надо будет раскомментировать и добавить проверку на InternetConnect).
Если зависание начинается после нескольких секунд работы - это вторая беда, connection closed gracefully тут ни при чем. То что я пофиксил - это ошибки скачки одного рабочего потока после как правило довольно продолжительной скачки (остановка, AV и т.п.), см. 6-й комментарий в этой теме и мой первый. |
|
|
|
|
>Ничего не понял
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
|
|
26-02-2012 08:46
|
|
|
Если счётчик очереди в статус строке (Queue) равен нулю, то видимо, проблема в TUiTileDownload (т.к. именно он инкрементит этот счётчик). |
|
|
|
|
>видимо, проблема в TUiTileDownload
Я при похожих зависаниях (срочно вырубал интерфейсные потоки отключением режима интернета) ставил бряк на InternetConnect и следующую строку, а также в даунлоадере на DoRequest и следующую строку. В обоих случаях выполнение останавливалось на втором бряке - то есть мы висели внутри InternetConnect и DoRequest соответственно - и по Disconnect оттуда радостно вылетали. Понятно, что это были два конкретных зависания, в других случаях может быть и другое.
|
|
|
|
(0005658)
|
|
zed
|
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
|
|
26-02-2012 13:19
|
|
> У меня при попытке выхода за эти границы вываливается ошибка паскаль-скрипта (TypeMismatch).
Интересно, почему у меня эта ошибка не вываливается?
Вообще-то логично: там массив не определён для этого зума. Я раньше об этом не подумал. Так паскаль-скрипт из-за этого тихо умирает?
Именно тихо, даже в параметрах карты показывает download state=yes. Но при переходе на правильный зум качать не начинает. Видимо, надо открыть другой баг-репорт про это?
На зуме, например, 17, если выйти далеко за пределы карты, тоже возникает ошибка 400. Она прям сразу не убивает качалку. Позже потестирую подольше, т.к. первоначально ошибка проявлялась не сразу. |
|
|
|
(0005662)
|
|
zed
|
|
26-02-2012 13:24
|
|
>Интересно, почему у меня эта ошибка не вываливается?
Потому что я под отладчиком это всё смотрел. Даже debug версия об обработанных ошибках не сообщает. Видимо где-то она там далее по коду тихо подавляется.
>надо открыть другой баг-репорт про это?
Да. |
|
|
|
|
|
Итого проверяем после всех исправлений. Есть бага? |
|
|
|
(0005694)
|
|
Tolik
|
|
28-02-2012 06:50
|
|
Вчера не зависала!
Сегодня хорошо проверить не могу, давайте ещё несколько дней погоняем. |
|
|
|
|
|
|
|
(0005778)
|
|
Tolik
|
02-03-2012 09:52
(edited on: 02-03-2012 10:10) |
|
Вроде больше не зависает! Хотя и не было времени специально гонять туда-сюда.
Вот только стала очень сильно грузить проц. при скролле.
Если нажать кнопку со стрелкой, карта движется медленно, с жуткими рывками, загрузка проц. повышается чуть ли не до 100%.
Это связано с новыми критическими секциями?
P.S. Например, версия 4891 движется заметно быстрее и более плавно, чем последняя (5140), проц. тоже загружается сильно, но не настолько.
А бета вообще летает, и загрузка проц. около нуля.
Такое ощущение, что каждая следующая версия тормозит всё сильнее :(
|
|
SASPlanet.Debug.elf (36,883) 16-02-2012 05:06
ALWininetHttpClient.rar (10,969) 25-02-2012 18:14
2012-02-26_073757.png (30,647) 26-02-2012 03:39