|
Notes |
|
|
|
|
|
|
|
Да бывает. Если качается по выделенной области и одновременно с этим иногда тычешься пальцем или автоматически качаются тайлы на экране. Даже счётчик загружаемых тайлов в статусбаре подвисает на 1 или 2 ))
Хотя если недавно в этом что-то менялось, то сорри... |
|
|
|
|
|
Вряд ли что-то помнялось. Я просто подозреваю что здесь ноги растут от туда же, откуда и в баге 0001215 |
|
|
|
(0007496)
|
|
Parasite
|
19-06-2012 06:04
(edited on: 19-06-2012 06:05) |
|
Еще такое может быть при плохом коннекте (особенно через проксики), когда подвисает сокет. По таймауту они иногда "забывают" отбиться.
Сохранение закачки в файл, перезапуск саса, восстановление прерванной закачки из файла. Ну или прибить висящий сокет на файрволе.
|
|
|
|
|
|
Может то может. Но мне интересно, можно ли с этим что-то сделать и нет ли еще каких-то причин для таких проблем. |
|
|
|
|
>мне интересно, можно ли с этим что-то сделать и нет ли еще каких-то причин для таких проблем.
Когда я ковырял описанные мною выше случаи - я упирался в системный TCP\IP стек и весьма загадочную отбивку по таймаутам там. То есть, оно иногда подвисало и на других приложениях по тому же сценарию, и сокет держался именно виндявым tcpip.sys. Видно, ему рвет крышу при каких-то конкретных условиях при проксифицировании, либо при длительной долбежке его мелкими запросами с высокой частотой и на плохой линии. Топикстартер это и описывал как раз...Коль скоро качает Яндекса десятками тысяч тайлов - то скорей всего через проксик, что и требовалось доказать.
PS: а под вынем такое повторить ни разу не смог. |
|
|
|
|
Ещё один вариант подвисания: если запустить одновременно закачку в несколько потоков (строго более одного). Один не виснет, два и более могут подвиснуть (все) примерно через десяток-два тысяч скачанных тайлов. Все счётчики скачанных тайлов останавливаются, причём молча, без каких либо сообщений в окне лога закачек!
И это не бан на яндексе - сохранение закачек в файл, перезапуск Планеты и продолжение всех закачек из файлов сразу же идёт дальше.
Все ip те же, прокси нет, подключение по Ethernet напрямую через роутер (в смысле не модемное), скорость канала в мегабитах. |
|
|
|
|
|
Ну не знаю. Перед майскими качал себе карты для поездок. Запускал по 5 закачек на картсервис и одновременно 6 картсервисов. И хоть бы раз зависло. |
|
|
|
|
|
Уточню, виснет именно яндекс (и карта и спутник и гибрид одновременно). И не сразу, а после over 10к тайлов. Другие картсервисы не виснут (или банят, это другое). Бинг не проверял. Сначала испугался что это из-за удаления версии из url для яндекса (чему я был инициатором), но вроде как нет, не влияет. |
|
|
|
|
|
Ааа. Ну я яндекс и бинг не качаю вообще, но все равно странно. |
|
|
|
|
|
В моем случае это часто бывало на GM и на маил.ру. |
|
|
|
|
|
Проверьте в последних ночных версиях. Кое что исправлялось возможно связанное с этим багом. |
|
|
|
(0008017)
|
|
Dima2000
|
01-08-2012 10:49
(edited on: 01-08-2012 10:51) |
|
Неа, не исправилось. Ночнушка сегодняшняя, 120801.6182. После обработки около 20к тайлов с карт яндекса (скачалось при этом 9к тайлов) на разных зумах закачка остановилась, только время идёт.
Зато переоткрытие сессии закачки (после сохранения в файл) продолжило процесс.
|
|
|
|
|
|
А это была дебажная версия? Если нет, то попробуйте в дебажной, может словится ошибка. |
|
|
|
|
|
Нет, то была не дебажная. Но и в дебажной всё ровно так же, проверил, никаких ошибок на экране не появляется. Из трёх запущенных сессий скачки карт яндекса две остановились (лишь оставшееся время увеличивается), а одна продолжает качать. В остановившихся последнее сообщение в логе "Загрузка с заменой...". |
|
|
|
|
Извиняюсь, третья сессия не качает, а опрашивает сервер, пока ни одного тайла не скачала, нету их в том зуме на сервере.
Счётчики удалённых и сохранённых тайлов (я качал с заменой) остановились на 58250:
/MapType/Map_(Yandex.Maps)/FileSystem/GetTileInfo__323809__0,51197528__0,00019207__0,00002211__01:02.193
/MapType/Map_(Yandex.Maps)/FileSystem/LoadTile________216__0,08020298__0,00835289__0,00007559__00:01.804
/MapType/Map_(Yandex.Maps)/FileSystem/SaveTile______58250__0,53633476__0,00455216__0,00045280__04:25.164
/MapType/Map_(Yandex.Maps)/BmpInMem/Add_______________124__0,00013076__0,00004043__0,00000344__00:00.005
/MapType/Map_(Yandex.Maps)/BmpInMem/Delete__________58250__0,00075802__0,00000214__0,00000096__00:00.125
/MapType/Map_(Yandex.Maps)/BmpInMem/Clear_______________2__0,00021088__0,00011764__0,00002440__00:00.000
/MapType/Map_(Yandex.Maps)/BmpInMem/CacheHit____________8__0,00001299__0,00000858__0,00000388__00:00.000
/MapType/Map_(Yandex.Maps)/BmpInMem/CacheMiss_________216__0,00052265__0,00003118__0,00000274__00:00.007 |
|
|
|
|
|
Совсем загадочно стало. И что, перезапуск только закачки спасает? |
|
|
|
|
Да, не паузу, а именно сохранение в файл (.sls) и открытие его заново. Спасает. Сам удивляюсь. Раньше не спасало, нужен был перезпуск всей Планеты.
Есть мысль что дело в переполнении каких-то буферов в винде (типа кол-ва соединений в tcp стеке или чего-то подобного), но как это проверить я не знаю. |
|
|
|
|
|
А проверить это все под отладчиком не сможете? Дождаться пока такое случиться, а потом в дебагере нажать на паузу и посмотреть стек потока, который закачку выполняет. |
|
|
|
|
Нет, отладчика нету, а скомпилить Планету (и запустить из под дельфи) не получается.
Подумалось, дело не в винде, скорее переполняются какие-то очереди сообщений в программе, потому что например построение карты заполнения качаемого зума тормозит закачку на время формирования карты в одном тайле. Заметил при карте заполнения +7, окно закачки обновляется рывками синхронно с обновлением карты заполнения. А после окончания построения карты заполнения для всего экрана закачка вообще идёт по тайлу в секунду (видимо посылает сообщение обновить карту и пока не обновится закачка не продолжается). |
|
|
|
|
|
Ну я и имел в виду скомпилить и запустить. В чем проблема с компиляцией? Нужна Delphi 2007 и содержимое репозитория https://bitbucket.org/zedxxx/sas.requires |
|
|
|
|
|
А торможения при построении карты заполнения скорее всего объясняются торможением файловой системы, то есть карта заполнения очень активно проверяет наличие тайлов и потоку закачки, который тоже должен проверить наличие тайла, а потом записать результат закачки приходится долго ждать. |
|
|
|
|
|
Проблема есть, вероятно лишь у меня. Да ещё кроме дельфи надо и HG (и/или кучу сторонних библиотек). Короче, не получается. |
|
|
|
|
|
Та ладно. HG совсем не обязателен. Все сторонние библиотеки есть здесь https://bitbucket.org/zedxxx/sas.requires Если делфа установлена, то настройка для компиляции занимает 10 минут максимум. |
|
|
|
(0008029)
|
|
Parasite
|
01-08-2012 14:25
(edited on: 01-08-2012 14:29) |
|
>дело не в винде, скорее переполняются какие-то очереди сообщений в программе
netstat -a
в студию
>вероятно лишь у меня.
У меня, как я и писАл выше - оно тоже повторяется. Обрыв подвисшего сокета - помогает без рестартов закачки\саса.
PS: а еще часто подвисает (и не обрывается) собственно запрос к DNSу при ресолвинге. 53й порт смотрите - САС в него долбится как тот хороший дятел. Локальный кэширующий ДНС (либо замена с доменного имени на IP) уменьшает вероятность появления проблемы раз эдак в 10, чего Вам и рекомендую со своей стороны.
|
|
|
|
|
>netstat -a в студию
А толку, от Планеты там лишь одна запись:
UDP 127.0.0.1:1245 *:*
Остальные TCP сессии (их штук 3-5 было) все закрылись сами.
При этом закачка висит в состоянии "Скачивание...". Уже с час висит, счётчики в Debug info стоят (кроме пары *Paint).
>замена с доменного имени на IP
Интересная мысль, попробую. Но вообще-то на днс запросы (кроме нескольких первых) должен роутер в локалке отвечать, он и закэширует.
>Проблема есть, вероятно лишь у меня.
Это я про компиляцию Планеты. :) Сорри что криво выразился. |
|
|
|
|
|
А может все-таки попробуете скомпилить? Проблема явно есть. А мне ее воспроизводить очень сложно, точнее вообще не получается. |
|
|
|
|
>А толку, от Планеты там лишь одна запись:
>UDP 127.0.0.1:1245 *:*
Вот она скорей всего и подвисла - TCPшные как правило и сами по таймауту хорошо отбиваются. САС в нормальном режиме работы не должен держать никаких открытых сокетов, тем более открытых дольше времени системного таймаута на эти сокеты. Проверяется просто - нажать у САСа на паузу и подождать время >timeout. Абсолютно все используемые САСом сокеты должны закрыться, если нет - то шаги ниже.
Вот попробуй эту сессию оборвать принудительно, НЕ ТРОГАЯ окно закачки саса (пускай так и стоит на скачке). У меня он при сабже мгновенно оживает и начинает просить следующий тайл в той же задаче скачки как ни в чем не бывало. Что и требуется доказать.
PS: и это проблема не саса, а винды и всего ее стека (включая все программы, сидящие "в разрывах" оного стека - например, файрволы и антивири). Аутпост например часто балуется переполнением драйвера своего файрвола и "не пусканием" очередного запроса от приложения N или от треда NN в Интернеты. Сабж можно повторить и в других приложениях - у меня например качательные скрипты тоже часто так виснут (особенно при запросах по домену, а не по ИПу), рубанешь им подвисший сокет - оживают и едут дальше.
>на днс запросы (кроме нескольких первых) должен роутер в локалке отвечать
Не должен. Раутер должен пробрасывать DNS-запросы до DNSов твоего провайдера через себя (которые ему выдаются при установлении сессии). У тебя же внутри раутера нет даже кэширующего DNS-сервера - так с какого перепугу тебе раутер должен отвечать на DNS-запросы? У него и 53й порт закрыт в большинстве случаев, а там где открыт - он бриджится на primary DNS провайдера практически всегда.
Поставь например BIND локально (как кэширующий), пропиши ему зону и укажи в системных настройках винды первым DNS-сервером 127.0.0.1. Качество и скорость связи намного вырастет, особенно в случаях многократной долбежки в одни и те же домены а не IP (привет САСовым закачкам).
http://yvision.kz/post/191388 |
|
|
|
|
|
Вряд ли именно эта конкретная проблема связана с зависанием сокета. Если бы это было так, то полный перезапуск закачки без перезапуска программы не помогал бы. Или хватало бы поставить закачку на паузу на пару минут. А так похоже таки глюк САС.Планеты. |
|
|
|
|
>полный перезапуск закачки без перезапуска программы не помогал бы
Для новой закачки вызывается новый тред. Некоторые файрволлы умеют фильтровать по-тредово, а не только по приложению. В частности - упомянутый выше глючный аутпост, под которым один тред может качать а соседний нет (в пределах одного приложения). Рестарт закачки меняет тред, соответственно - новый тред начинает работать (до следующего глюка). Наблюдпал лично на оном аутпосте не раз. Если продолжать долбиться и не рестартовать всю винду - то в итоге будет системный еррор "недостаточно ресурсов для завершения операции" при попытке доступа в сеть, хотя казалось бы ничего более в системе сеть не юзает. Просто вся очередь забита висящими тредами, причем висят они со стороны файрвола а не со стороны саса. Закрытие саса поэтому не помогает - файрвол все так же держит очередь со своей стороны, и надо ребутать всю систему, что переинициализирует файровол.
Я об этом когда-то сюда писАл тикет уже, про блокаду сетевых операций (кой есть просто крайнее положение вот этого вот - ибо качаю я помногу и постоянно, а ребутаться очень не люблю). Там как раз был виноват именно Аутпост - удаление его с системы полностью решило вопрос [там]. Но поплясать с дебаггером и разнообразными тулзами от Руссиновича пришлось дооолго, да...
Надо бы кстати дописать в тот тикет, в чем причина была. Авось кому поможет еще. :)
>Или хватало бы поставить закачку на паузу на пару минут
Проблема в том что сокет подвисал в состоянии TIME_WAIT со стороны файрвола, имеющего собственный драйвер "в разрыве" виндового стека. Винда не может отбить такой зависший стейт по таймауту просто потому, что привилегии у двух драйверов уровня ядра (tcpip.sys и opfw.sys, или как там его у Аутпоста) - равны. Вот и получается, что первый приказать не может и просто ждет второго - до бесконечности. При перезапуске закачки\САСа - мы просто открываем еще один тред рядом и он работает до поры до времени, но висящего старого оно таки не убивает. В итоге в определенный момент времени весь пул выюзывается, и извольте ребутать ось. У меня это было каждые 2-3 дня при массовых скачках, и многократно усиливалось если качать на сетевую щару а не на винт (бо SMB тоже шло через тот же глючный файрвол). Тикет 810, собссно: http://sasgis.org/mantis/view.php?id=810
>А так похоже таки глюк САС.Планеты.
В моем случае оно было повторяемо и на собственных скриптах, САС вообще не запускался. Как там у тикетстартера - ему виднее. |
|
|
|
|
>Для новой закачки вызывается новый тред.
В новых версиях, тред обеспечивающий закачку по региону сам ничего не качает, а только ставит задания на закачку, которые обрабатываются пулом тредов-качальщиков. А треды из этого пула умирают только по времени неиспользования.
Так что общего с твоим багом ничего нет. |
|
|
|
(0008040)
|
|
Parasite
|
02-08-2012 06:17
(edited on: 02-08-2012 06:19) |
|
>треды из этого пула умирают только по времени неиспользования.
Они могут умереть не дождавшись закрытия соединения которое держится с другой стороны? Да\нет, и если да - то что будет с незакрытым соединением оставшемся без вызвавшего его треда (и со всей твоей очередью качальщиков - при заполнении уже системной очереди открытых соединений, которые не могут быть закрыты по системному таймауту)?
Не забываем, что например в ХП СП2\3(а именно оно в тикете) дефолтовая очередь всего 10 полуоткрытых соединений до к.хоста, так что сабжа долго ждать не придется если драйвер не патченый.
>Так что общего с твоим багом ничего нет.
Я и не настаиваю, что тут - одно и то же.
Просто у меня уже было нечто весьма похожее на описываемое в неск.последних постах. Причем на той же системе что и у тикетстартера, а у тебя - другая (в семерке не нужен патч драйвера) - посему у тебя оно может тупо не повторяться на весьма коротком времени использования. Мое дело - намекнуть если я подобное уже видел, а там сами разбирайтесь. :)
|
|
|
|
|
Файера у меня нет, потому аутпост ни причём.
Исчерпание какого-то там пула соединений выглядит по другому, вот с утра любуюсь, с трудом создаются новые соединения и не всегда удаётся что-то вообще скачать (во ВСЕХ программах), аська даже не может подключиться. А САС пишет в окне лога закачки "нет соединения с интернет".
Tcpip.sys пропатчен, до 500 half open.
Всего соединений порядка 30-ти (по netstat -a): десяток tcp в состоянии listening, пяток активных (от разных программ), и десяток udp открыто.
UDP соединение открывается САС-ом сразу по запуску и держится постоянно. Ровно одно, со случайного порта. Независимо есть закачка или нет. С подвисанием закачки имхо не связано.
Мне непонятно почему окно закачки висит если ВСЕ tcp соединения уже закрылись? А спустя несколько минут это так и есть. Причём висит в состоянии закачки (ожидания ответа сервера?). В настройках САС-а таймаут стоит 500мс. Получается внутренняя качалка закрылась/остановилась по таймауту, соединения закрылись, а окну закачки об этом никто не сказал и оно всё ещё ждёт ответа (с тайлом) ... |
|
|
|
|
|
Еще раз прошу откомпилировать и запустить в отладке. Это будет гораздо быстрее и полезнее абстрактных рассуждений на тему "что же там могло случиться". |
|
|
|
|
>Файера у меня нет
Ну, во-первых в ХП свой фаер есть, для начала.
А во-вторых - антивирь установлен? Часто там тоже куча модулей ставится на контроль трафика.
>с трудом создаются новые соединения и не всегда удаётся что-то вообще скачать (во ВСЕХ программах), аська даже не может подключиться.
Либо ДНСы, либо интернет такой, либо система тупит, либо всё вместе. Имхо, все же не САС.
>UDP соединение открывается САС-ом сразу по запуску и держится постоянно.
Помнится, когда-тоне так давно при запуске оно ломилось на феевый счетчик - для статистики. Не знаю, как оно сейчас - вдемидов прояснит, он более в теме. Но с любой стороны - зачем бы ему открывать соединение именно при старте? Автообновлялок там нет, и если режим "только кэш" - то не вижу вообще смысла ему делать соединения при старте. |
|
|
|
|
>Ну, во-первых в ХП свой фаер есть, для начала.
Отключен.
>А во-вторых - антивирь установлен?
Да, но без всех сетевых модулей.
>Имхо, все же не САС.
В данном случае да, не САС. Привёл для демонстрации отличий в поведении САС-а. Что к зависшей закачке эта причина не влияет.
>и если режим "только кэш" - то не вижу вообще смысла ему делать соединения при старте.
Разумеется при старте САС-а режим именно "только кэш". Я тоже не вижу смысла. Просто это тоже имхо не относится к причинам зависания закачки.
>Еще раз прошу откомпилировать и запустить в отладке.
Повторяю, не могу (не получается). И разбираться почему недосуг. Вы всех пользователей будете просить откомпилить программу? ;-) Поведение САС-а описал, какую мог инфу получить - написал. А заниматься отладкой сейчас нет возможности. |
|
|
|
|
>но без всех сетевых модулей.
То, что они не работают - еще не значит, что их нет. Тот же Каспер (KIS) например сперва ставит всю свою кучу драйверов и обработчиков в полном составе и просит ребута для их задействования, а потом их можно включать сугубо в Ring3 (а в Ring0 они активны постоянно - просто могут делать bypass если в данный момент не используются. При этом сами дрова все так же висят в памяти, и данные все так же шастают через них - просто никаких действий собственно KISa над ними не делается. Теоретически). Это как драйвер вайршарка например - PCcap ставится в систему разово и весь поток идет через него с момента установки, а вайрщарк просто умеет "отсасывать" данные от этого драйвера по необходимости. То, что вайршарк в какой-то момент не запущен - еще не значит, что PCcap не в памяти и что его теоретические глюки не могут влиять на трафик. Так и у антивирей.
Что за антивирь у тебя?
>Просто это тоже имхо не относится к причинам зависания закачки.
Как показывает многолетняя практика - к причинам может относиться все что угодно вплоть до магнитной бури на Венере. Например глючащий драйвер не отдает САСу флаг успешного закрытия сокета в том виде, в каком ее ждет САС (корежит инфу в каком-то неопределенном месте) - и получается сабжевое ожидание слепого глухим.
Запустил бы ты вайршарка, да поглядел бы что там по сокетам бегает и кто кого ждет. И наверное это лучше на форум, так как собственно САСового _конкретного_ бага я тут до сих пор не вижу - а вижу непонятные глюк всей системы, и еще неизвестно где собачка порылась. А то тебя вдемидов с такими багрепортами быстро отправит видео всего процесса писАть и счетчики приаттачивать вплоть до 2020го года.... :)
А систему в любом случае надо лечить. |
|
|
|
|
>>Еще раз прошу откомпилировать и запустить в отладке.
>Повторяю, не могу (не получается). И разбираться почему недосуг. Вы всех пользователей будете просить откомпилить программу? ;-) Поведение САС-а описал, какую мог инфу получить - написал. А заниматься отладкой сейчас нет возможности.
Нет. Только программистов. Но при таких условиях, и при том что у меня баг не воспроизводится. То решение бага откладывается, пока у вас не появится возможность подебажить. Ну или может случайно вылечиться. |
|
|
|
|
>Что за антивирь у тебя?
BitDefender 8 Professional Plus, весьма старый, года 3 или 4, обновляются лишь базы. Сетевой модуль отключен. В свойствах сетевухи ничего лишнего нет.
Проблема наблюдалась не только у меня, а и как минимум у T_Im. Т.е. не факт что виновата лишь моя кривая ОС.
И ещё странно что проблема наблюдается лишь при закачке с яндекса, а не со всех сервисов. И только если сессий закачки больше одной.
Ок, бум ждать случайного исправления или воспроизводимости. При случае попробую на соседнем компе. И с IP идею проверю. |
|
|
|
|
>Проблема наблюдалась не только у меня, а и как минимум у T_Im.
Не факт, что это на 100% одна и так же проблема (так как в обсуждении он не участвует и более подробных каментов не дает). Также не факт, что один и тот же результат не может быть при действии совершенно разных причин.
>странно что проблема наблюдается лишь при закачке с яндекса, а не со всех сервисов. И только если сессий закачки больше одной.
Всё ж попробуй локальный DNS поднять и проверить. Что-то сомнительно мне именно в эту сторону. Помнится, у тебя и с торрент-трекером были проблемы месяц назад - и как раз тоже в сторону DNS. |
|
|
|
|
Вот прямо сейчас качаю Гугла в несколько потоков - и спорадически один-два из потоков подвисают без видимой причины (при этом соседние - качают себе). Кэширующий ДНС таки установлен. Сокеты на подвисших задачах при этом НЕ висят, и даже не открыты. Скачка идет через проксик на локалхосте, и если и зависнут со стороны САСа - были бы видны на проксике (как это было в старых версиях). В данном случае этого нет - САС просто "задумался" сам по себе. Надпись "Downloading..." в окошке закачки, и на этом всё.
Похоже, таки действительно где-то пробрался злобный баг при качке несколькими параллельными тредами с одного сервиса. Пока качал в один поток - такого вроде как не было, сейчас же проявляется с завидной регулярностью где-то раз в сутки. vdemidov, говори куда потестить пока оно повторяемо... |
|
|
|
(0009017)
|
|
Parasite
|
24-09-2012 03:03
(edited on: 24-09-2012 03:17) |
|
>САС просто "задумался" сам по себе
Господа, с этим надо что-то делать. Давайте займемся? Баг повторяется как минимум на моей стороне, причем многократно и ежедневно.
Dima2000, а у тебя оно случаем останавливается не на скачках в кэш Беркли? Что-то у меня по непроверенной статистике вроде как остановки только там, где качается напрямую в Беркли. Если качается в обычный тайловый кэш - вроде как сабжа нет.
100% не дам, но вот сегодня 6 из 40 потоков зависли за ночь, и все - на скачке, идущей в Беркли и на картах, где в один беркли-кэш качается в несколько потоков а не в один поток на к.зум. Случайность или нет - ХЗ. Помониторю еще, но баг таки да - уже весьма достаёт.
UPD: а нет, отбой. Только что остановился поток скачки в обычный тайловый кэш. :(
|
|
|
|
|
Нет, я беркли использую лишь на чтение (чужие входящие файлы), а так в стандартный кэш.
Что странно, у меня остановка проявляется лишь при скачке с яндекса и лишь если одновременно более одной закачки с него идёт. С гугла и прочих эффекта нет, как и нет если закачка с яндекса ровно одна. Но возможно яндекс просто быстрее отдаёт, а на остальных я не успеваю (до бана) налететь на глюк ... |
|
|
|
(0009027)
|
|
zed
|
|
24-09-2012 20:44
|
|
> сегодня 6 из 40 потоков зависли за ночь
O_o, у тебя открыто одновременно 40 окошек с закачками? Сколько же всего потоков у САСа в диспетчере задач отсвечивает? И потоки именно висят или может они повылетали к чёрту?
Если дебажная версия эксепшены не выдаёт, то похоже что тут дедлок. Поэксперементируй на какой-то одной карте, чтобы гарантированно отловить какое число потоков и при каком числе разрешённых соединений с сервером приводят к багу. Я так понял, что при MaxConnectToServerCount=1 всё работает нормально? |
|
|
|
(0009028)
|
|
zed
|
|
24-09-2012 20:51
|
|
|
Кстати, под отладчиком все потоки подписаны и там было бы легко отследить сколько именно потоков и каких именно работает на закачку и не отвалилось ли чего... |
|
|
|
|
>остановка проявляется лишь при скачке с яндекса и лишь если одновременно более одной закачки с него идёт. С гугла и прочих эффекта нет, как и нет если закачка с яндекса ровно одна.
У меня повторяемо на гугл.гибриде (щас как раз раздача его идет на трекере), а также на DG и яндексе.
И да, натыкается тогда когда потоков больше одного. Всегда. Что-то говорит мне, что с очередью к скачке в САСе что-то не того....Ибо подвисает не сокет - открытых сокетов на подвисшем сасе нет. Он сам по себе тупит, не выходя наружу.
>O_o, у тебя открыто одновременно 40 окошек с закачками?
Вообще-то раза в 4 больше. Но это не на одном САСе, не волнуйся ты так. Их много, запущенных параллельно...Некоторые - годами. :)
>Если дебажная версия эксепшены не выдаёт, то похоже что тут дедлок.
Никаких (видимых) эксепшнов не выдается. Поток просто качает до поры до времени, потом бегущие строчки в нем останавливаются на строке "Downloading..." и так и висит пока ручки не приложишь (как-то ждал 3 суток - не, так и не просрало). При этом ни само окошечко, ни САС - не зависшие как таковые. Окошечко можно закрыть штатными средствами и рестартануть, и соседние окошки в том же сасе - качают ОК.
Останавливается именно закачка в конкретном потоке скачки. При этом открытых сокетов у САСа с подвисшими окошками НЕТ ни одного, так что проблемс явно не в интернете как это было у старых версий в похожих ситуациях.
>Поэксперементируй на какой-то одной карте, чтобы гарантированно отловить какое число потоков и при каком числе разрешённых соединений с сервером приводят к багу.
Гугл гибрид, качка в 4 потока - два потока практически гарантированно зависают в течении суток. Остальные 2 - качают.
Иногда 3\1.
Но так, чтобы зависли 4 из 4х - ни разу не было, опять же.
>Я так понял, что при MaxConnectToServerCount=1 всё работает нормально?
Не знаю, этот сеттингс не пробовал.
Но даже при дефолтовом MaxConnectToServerCount=20 (у меня) но при скачке в одно окошечко - сабж у меня ни разу не повторялся. Не утверждаю что его совершенно нет при скачке в одно рыло - но до сих пор не подвисало. |
|
|
|
(0009031)
|
|
zed
|
|
25-09-2012 08:28
|
|
>Не знаю, этот сеттингс не пробовал.
Попробуй.
>Поток просто качает до поры до времени, потом бегущие строчки в нем останавливаются
Не путай окошко, которое ты видишь и поток, который создаётся для закачки. Они как бы независимы, а окошко просто берёт статистику от потока и умеет его останавливать/убивать. Может статься, что закачка вообще-то идёт, но затык с передачей статистики. |
|
|
|
|
>Попробуй.
Попробую. Но что-то говорит мне, что всё будет ровно так как будто я открою одно окошко (с которым и так работает).
>Может статься, что закачка вообще-то идёт, но затык с передачей статистики.
Слова "на подвисшем процессе отрытых сокетов НЕТ" - для кого? Закачка идет без активности в сокетах, и даже на проксике ничего не светится? Забористо у вас там после отпуска, мне бы так. :) |
|
|
|
(0009033)
|
|
zed
|
|
25-09-2012 09:25
|
|
|
Ты же писал, что у тебя только часть закачек подвисла, а часть продолжает работать, т.е. сокеты должны быть открыты в любом случае. |
|
|
|
|
>а часть продолжает работать, т.е. сокеты должны быть открыты в любом случае.
Ну за дурака-то не держи. :) Я их предварительно вырубил, когда смотрел - есть активность только на подвисших или нет.
Активности не было ни в окошке (текстом), ни на локальном проксике (в логах), ни в статистике соединений в системе (ни в TIME_WAIT ни в ESTABLISHED ни в CLOSING). |
|
|
|
|
Подтверждаю, я тоже специально проверял, при подвисании закачек вообще ничего не идёт от них по сети и сокетов открытых нету (точнее все открытые не относятся к закачкам).
И да, никаких видимых ошибок нет, как нет и подвисаний ничего кроме самой закачки. Дебажная версия тут не помошник.
Ещё, надо бы уточнять на каких версиях проявляется. А то вдемидов недавно добавлял блокировок в файловых хранилищах, вдруг оно поправилось? |
|
|
|
(0009040)
|
|
zed
|
|
25-09-2012 21:20
|
|
|
Выложил на торренте виртуалку с настроенной делфи - кого беспокоит баг и интересно его победить, попробуйте запустить САС под отладчиком и посмотреть, будут ли там какие нехорошие сообщения. |
|
|
|
|
>кого беспокоит баг и интересно его победить, попробуйте запустить САС под отладчиком и посмотреть, будут ли там какие нехорошие сообщения.
А минимальный текст бы - куда в там нажимать и в какую сторону смотреть? Вот лично я в этой вашей дельфе не ездун, и чего конкретно и пошагово в ней делать - даже не представляю. |
|
|
|
(0009044)
|
|
zed
|
26-09-2012 06:43
(edited on: 26-09-2012 06:50) |
|
|
|
|
|
>Зелёненькая стрелочка Run или горячая клавиша F9 запускает проект на выполнение под отладчиком.
Это понятно. А дальше?
Допустим, запустилось оно. Начало качать. Повторился этот баг. Дальше - что? |
|
|
|
(0009046)
|
|
zed
|
|
26-09-2012 06:51
|
|
> Дальше - что?
А дальше - "посмотреть, будут ли там какие нехорошие сообщения." |
|
|
|
(0009096)
|
|
Parasite
|
01-10-2012 17:39
(edited on: 01-10-2012 17:40) |
|
Удалось поймать кусок корявого лога в окне закачки, после которого через некоторое время закачка подвисла.
Не знаю, причина это или следствие - так что просто оставлю это тут.
В окне закачки:
-----------------
Отсутствует подключение к интернет!
Пауза 5 секунд...
Обработка файла: I:\SAS\cache_db\Both\z14\0\0\2.2.sdb\x627\y607.png ...
Downloading...
Отсутствует подключение к интернет!
Пауза 5 секунд...
Обработка файла: I:\SAS\cache_db\Both\z14\0\0\2.2.sdb\x627\y607.png ...
Downloading...
Отсутствует подключение к интернет!
Пауза 5 секунд...
Обработка файла: I:\SAS\cache_db\Both\z14\0\0\2.2.sdb\x627\y607.png ...
Downloading...
-----------------
И все бы ничего, но при этом на проксик приходит следующий УРЛ
-----------------
01.10.2012/21:13:29 local/127.0.0.1 http://mt2.google.com/vt?v=w2t.999&hl=en&x=627&y=607&zoom=4&s= 0 0/144 0 0 "Client disconnected"
-----------------
Явно видно, что параметр "ЗУМ" побился с 14го качаемого на 4й генерируемый в УРЛе, а также побился хвост урла ("s=Galileo"). На гугле на 4м уровне нет координат x=627&y=607, и отсюда "Отсутствует подключение".
Через пару минут - закачка подвисла на стадии "Downloading", на проксик в этот раз не пришло вообще ничего. Рестарт закачки - начало качать как обычно, урлы генерировались правильные, итд по тексту этого тикета. Пока что работает.
Такое ощущение что что-то где-то влазит в зону памяти работающего паскальскрипта из ЗМП и корежит оную.
Надеюсь, чем-нибудь да поможет.
PS: ZMP - штатный Гугл Гибрид.
|
|
|
|
|
Удалось воспроизвести в зедовой виртуалке под отладчиком.
Скрины - вверху.
Закачка шла в 4 потока в кэш беркли, штатный ZMP Гугл.Гибрид, 14й уровень, весь мир 2х2 = 4 квадратных выделения.
1. Скрин 1. Уже зависло в левом верхнем потоке.
2. Скрин 2 - через пару минут от Скрин 1. Статистика по скачанным левого верхнего потока - не изменилась. Висим-сс - что и есть сабж. Через некоторое время (в течении суток) зависнут еще 2 потока, а самый последний будет качать как ни в чем ни бывало до победного конца.
3. Скрин 3 по потокам с дебаггера.
4. EventLog с него же - ниже.
zed, напиши куда еще посмотреть. Я пока программу\виртуалку не закрываю, и жду твоего тонкого руководства. Тикету пока поставлю критический приоритет - ибо жизни нет, основной функционал САСа таки отвалился.
-----------------------
Thread Start: Thread ID: 360. Process SASPlanet.exe (220)
Process Start: C:\SASPlanet\.bin\SASPlanet.exe. Base Address: $00400000. Process SASPlanet.exe (220)
Module Load: SASPlanet.exe. Has Debug Info. Base Address: $00400000. Process SASPlanet.exe (220)
Module Load: ntdll.dll. No Debug Info. Base Address: $7C900000. Process SASPlanet.exe (220)
Module Load: KERNEL32.dll. No Debug Info. Base Address: $7C800000. Process SASPlanet.exe (220)
Module Load: OLEAUT32.dll. No Debug Info. Base Address: $77110000. Process SASPlanet.exe (220)
Module Load: ADVAPI32.dll. No Debug Info. Base Address: $77DC0000. Process SASPlanet.exe (220)
Module Load: RPCRT4.dll. No Debug Info. Base Address: $77E70000. Process SASPlanet.exe (220)
Module Load: Secur32.dll. No Debug Info. Base Address: $77FE0000. Process SASPlanet.exe (220)
Module Load: GDI32.dll. No Debug Info. Base Address: $77F10000. Process SASPlanet.exe (220)
Module Load: USER32.dll. No Debug Info. Base Address: $7E360000. Process SASPlanet.exe (220)
Module Load: msvcrt.dll. No Debug Info. Base Address: $77C00000. Process SASPlanet.exe (220)
Module Load: ole32.dll. No Debug Info. Base Address: $774D0000. Process SASPlanet.exe (220)
Module Load: VERSION.dll. No Debug Info. Base Address: $77BF0000. Process SASPlanet.exe (220)
Module Load: COMCTL32.dll. No Debug Info. Base Address: $773C0000. Process SASPlanet.exe (220)
Module Load: SHLWAPI.dll. No Debug Info. Base Address: $77F60000. Process SASPlanet.exe (220)
Module Load: IMM32.dll. No Debug Info. Base Address: $76360000. Process SASPlanet.exe (220)
Module Load: urlmon.dll. No Debug Info. Base Address: $45020000. Process SASPlanet.exe (220)
Module Load: iertutil.dll. No Debug Info. Base Address: $40080000. Process SASPlanet.exe (220)
Module Load: WININET.dll. No Debug Info. Base Address: $3F9E0000. Process SASPlanet.exe (220)
Module Load: Normaliz.dll. No Debug Info. Base Address: $00340000. Process SASPlanet.exe (220)
Module Load: SHELL32.dll. No Debug Info. Base Address: $7C9C0000. Process SASPlanet.exe (220)
Module Load: comdlg32.dll. No Debug Info. Base Address: $76380000. Process SASPlanet.exe (220)
Module Load: WINMM.dll. No Debug Info. Base Address: $76B20000. Process SASPlanet.exe (220)
Module Load: jpeg62.dll. No Debug Info. Base Address: $10000000. Process SASPlanet.exe (220)
Module Load: MSVCR100.dll. No Debug Info. Base Address: $78AA0000. Process SASPlanet.exe (220)
Module Load: FreeImage.dll. No Debug Info. Base Address: $00360000. Process SASPlanet.exe (220)
Module Load: libpng15.dll. No Debug Info. Base Address: $003C0000. Process SASPlanet.exe (220)
Module Load: zlib1.dll. No Debug Info. Base Address: $00930000. Process SASPlanet.exe (220)
Module Load: MSVCP100.dll. No Debug Info. Base Address: $78050000. Process SASPlanet.exe (220)
Thread Start: Thread ID: 408. Process SASPlanet.exe (220)
Module Load: MSCTF.dll. No Debug Info. Base Address: $746E0000. Process SASPlanet.exe (220)
Module Load: msctfime.ime. No Debug Info. Base Address: $75310000. Process SASPlanet.exe (220)
Module Load: UxTheme.dll. No Debug Info. Base Address: $5B260000. Process SASPlanet.exe (220)
Module Load: MSIMG32.dll. No Debug Info. Base Address: $76350000. Process SASPlanet.exe (220)
Module Load: OLEPRO32.DLL. No Debug Info. Base Address: $5F2F0000. Process SASPlanet.exe (220)
Module Load: UNKNOWN_MODULE_2. No Debug Info. Base Address: $013F0000. Process SASPlanet.exe (220)
Module Load: UNKNOWN_MODULE_3. No Debug Info. Base Address: $20000000. Process SASPlanet.exe (220)
Thread Start: Thread ID: 1192. Process SASPlanet.exe (220)
Module Load: WS2_32.dll. No Debug Info. Base Address: $71A90000. Process SASPlanet.exe (220)
Module Load: WS2HELP.dll. No Debug Info. Base Address: $71A80000. Process SASPlanet.exe (220)
Thread Start: Thread ID: 1604. Process SASPlanet.exe (220)
Module Load: RASAPI32.dll. No Debug Info. Base Address: $76ED0000. Process SASPlanet.exe (220)
Module Load: rasman.dll. No Debug Info. Base Address: $76E80000. Process SASPlanet.exe (220)
Module Load: NETAPI32.dll. No Debug Info. Base Address: $5BD50000. Process SASPlanet.exe (220)
Module Load: TAPI32.dll. No Debug Info. Base Address: $76EA0000. Process SASPlanet.exe (220)
Thread Start: Thread ID: 844. Process SASPlanet.exe (220)
Module Load: rtutils.dll. No Debug Info. Base Address: $76E70000. Process SASPlanet.exe (220)
Module Load: USERENV.dll. No Debug Info. Base Address: $769A0000. Process SASPlanet.exe (220)
Module Load: SensApi.dll. No Debug Info. Base Address: $72290000. Process SASPlanet.exe (220)
Module Load: MSAPSSPC.dll. No Debug Info. Base Address: $71E30000. Process SASPlanet.exe (220)
Module Load: MSVCRT40.dll. No Debug Info. Base Address: $03470000. Process SASPlanet.exe (220)
Module Unload: MSAPSSPC.dll. Process SASPlanet.exe (220)
Module Unload: MSVCRT40.dll. Process SASPlanet.exe (220)
Module Load: SCHANNEL.dll. No Debug Info. Base Address: $767D0000. Process SASPlanet.exe (220)
Module Load: CRYPT32.dll. No Debug Info. Base Address: $77A70000. Process SASPlanet.exe (220)
Module Load: MSASN1.dll. No Debug Info. Base Address: $77B10000. Process SASPlanet.exe (220)
Module Unload: SCHANNEL.dll. Process SASPlanet.exe (220)
Module Unload: CRYPT32.dll. Process SASPlanet.exe (220)
Module Unload: MSASN1.dll. Process SASPlanet.exe (220)
Module Load: DIGEST.dll. No Debug Info. Base Address: $75E40000. Process SASPlanet.exe (220)
Module Unload: DIGEST.dll. Process SASPlanet.exe (220)
Module Load: MSNSSPC.dll. No Debug Info. Base Address: $742E0000. Process SASPlanet.exe (220)
Module Load: MSVCRT40.dll. No Debug Info. Base Address: $03470000. Process SASPlanet.exe (220)
Module Unload: MSNSSPC.dll. Process SASPlanet.exe (220)
Module Unload: MSVCRT40.dll. Process SASPlanet.exe (220)
Module Load: msv1_0.dll. No Debug Info. Base Address: $77C60000. Process SASPlanet.exe (220)
Module Load: cryptdll.dll. No Debug Info. Base Address: $76770000. Process SASPlanet.exe (220)
Module Load: iphlpapi.dll. No Debug Info. Base Address: $76D50000. Process SASPlanet.exe (220)
Thread Start: Thread ID: 520. Process SASPlanet.exe (220)
Module Load: CLBCatQ.DLL. No Debug Info. Base Address: $76FC0000. Process SASPlanet.exe (220)
Module Load: COMRes.dll. No Debug Info. Base Address: $03580000. Process SASPlanet.exe (220)
Module Load: IEFRAME.dll. No Debug Info. Base Address: $40270000. Process SASPlanet.exe (220)
Module Load: PSAPI.DLL. No Debug Info. Base Address: $76BE0000. Process SASPlanet.exe (220)
Thread Start: Thread ID: 532. Process SASPlanet.exe (220)
Thread Start: Thread ID: 1436. Process SASPlanet.exe (220)
Thread Start: Thread ID: 1612. Process SASPlanet.exe (220)
Thread Start: Thread ID: 1564. Process SASPlanet.exe (220)
Module Load: sxs.dll. No Debug Info. Base Address: $7E690000. Process SASPlanet.exe (220)
Module Load: appHelp.dll. No Debug Info. Base Address: $77B30000. Process SASPlanet.exe (220)
Thread Start: Thread ID: 1280. Process SASPlanet.exe (220)
Thread Start: Thread ID: 560. Process SASPlanet.exe (220)
Module Load: MSHTML.dll. No Debug Info. Base Address: $03910000. Process SASPlanet.exe (220)
Module Load: msls31.dll. No Debug Info. Base Address: $74680000. Process SASPlanet.exe (220)
Module Load: MLANG.dll. No Debug Info. Base Address: $75DA0000. Process SASPlanet.exe (220)
Thread Start: Thread ID: 1964. Process SASPlanet.exe (220)
Module Load: MSWSOCK.dll. No Debug Info. Base Address: $71A30000. Process SASPlanet.exe (220)
Thread Start: Thread ID: 576. Process SASPlanet.exe (220)
Module Load: HNetCfg.dll. No Debug Info. Base Address: $698B0000. Process SASPlanet.exe (220)
Module Load: WSHTCPIP.dll. No Debug Info. Base Address: $71A70000. Process SASPlanet.exe (220)
Module Load: rasadhlp.dll. No Debug Info. Base Address: $76FB0000. Process SASPlanet.exe (220)
Module Load: DNSAPI.dll. No Debug Info. Base Address: $76F10000. Process SASPlanet.exe (220)
Thread Start: Thread ID: 572. Process SASPlanet.exe (220)
Thread Start: Thread ID: 1012. Process SASPlanet.exe (220)
Thread Start: Thread ID: 724. Process SASPlanet.exe (220)
Thread Start: Thread ID: 1452. Process SASPlanet.exe (220)
Thread Start: Thread ID: 900. Process SASPlanet.exe (220)
Thread Start: Thread ID: 1472. Process SASPlanet.exe (220)
Thread Start: Thread ID: 1488. Process SASPlanet.exe (220)
Thread Exit: Thread ID: 844. Process SASPlanet.exe (220)
Thread Exit: Thread ID: 572. Process SASPlanet.exe (220)
Thread Exit: Thread ID: 724. Process SASPlanet.exe (220)
Thread Exit: Thread ID: 1488. Process SASPlanet.exe (220)
Thread Exit: Thread ID: 1452. Process SASPlanet.exe (220)
Thread Exit: Thread ID: 900. Process SASPlanet.exe (220)
Thread Exit: Thread ID: 1472. Process SASPlanet.exe (220)
Module Load: libdb51.dll. No Debug Info. Base Address: $02830000. Process SASPlanet.exe (220)
Thread Start: Thread ID: 252. Process SASPlanet.exe (220)
Thread Start: Thread ID: 904. Process SASPlanet.exe (220)
Thread Start: Thread ID: 120. Process SASPlanet.exe (220)
Thread Start: Thread ID: 1028. Process SASPlanet.exe (220)
Thread Start: Thread ID: 1992. Process SASPlanet.exe (220)
Thread Start: Thread ID: 1032. Process SASPlanet.exe (220)
Thread Exit: Thread ID: 904. Process SASPlanet.exe (220)
Thread Exit: Thread ID: 252. Process SASPlanet.exe (220)
Thread Exit: Thread ID: 1992. Process SASPlanet.exe (220)
Thread Exit: Thread ID: 120. Process SASPlanet.exe (220)
Thread Exit: Thread ID: 1032. Process SASPlanet.exe (220)
Thread Exit: Thread ID: 1028. Process SASPlanet.exe (220)
Thread Exit: Thread ID: 408. Process SASPlanet.exe (220)
Module Load: TORTOISEOVERLAYS.dll. No Debug Info. Base Address: $05960000. Process SASPlanet.exe (220)
Module Load: THgShellx86.dll. No Debug Info. Base Address: $02970000. Process SASPlanet.exe (220)
Module Load: msi.dll. No Debug Info. Base Address: $04E00000. Process SASPlanet.exe (220)
Module Load: BROWSEUI.dll. No Debug Info. Base Address: $75F50000. Process SASPlanet.exe (220)
Module Load: SETUPAPI.dll. No Debug Info. Base Address: $05240000. Process SASPlanet.exe (220)
Module Load: ntshrui.dll. No Debug Info. Base Address: $76970000. Process SASPlanet.exe (220)
Module Load: ATL.DLL. No Debug Info. Base Address: $76B00000. Process SASPlanet.exe (220)
Thread Start: Thread ID: 196. Process SASPlanet.exe (220)
Module Load: SHDOCVW.dll. No Debug Info. Base Address: $049C0000. Process SASPlanet.exe (220)
Module Load: CRYPT32.dll. No Debug Info. Base Address: $77A70000. Process SASPlanet.exe (220)
Module Load: MSASN1.dll. No Debug Info. Base Address: $77B10000. Process SASPlanet.exe (220)
Module Load: CRYPTUI.dll. No Debug Info. Base Address: $76650000. Process SASPlanet.exe (220)
Module Load: WINTRUST.dll. No Debug Info. Base Address: $76C20000. Process SASPlanet.exe (220)
Module Load: IMAGEHLP.dll. No Debug Info. Base Address: $76C80000. Process SASPlanet.exe (220)
Module Load: WLDAP32.dll. No Debug Info. Base Address: $76F50000. Process SASPlanet.exe (220)
Module Load: RICHED20.dll. No Debug Info. Base Address: $74DF0000. Process SASPlanet.exe (220)
Module Unload: RICHED20.dll. Process SASPlanet.exe (220)
Thread Start: Thread ID: 1040. Process SASPlanet.exe (220)
Module Load: LINKINFO.dll. No Debug Info. Base Address: $76960000. Process SASPlanet.exe (220)
Thread Start: Thread ID: 440. Process SASPlanet.exe (220)
Thread Start: Thread ID: 296. Process SASPlanet.exe (220)
Thread Start: Thread ID: 1640. Process SASPlanet.exe (220)
Thread Start: Thread ID: 460. Process SASPlanet.exe (220)
Thread Start: Thread ID: 476. Process SASPlanet.exe (220)
Thread Exit: Thread ID: 1040. Process SASPlanet.exe (220)
Thread Exit: Thread ID: 196. Process SASPlanet.exe (220)
Thread Exit: Thread ID: 440. Process SASPlanet.exe (220)
Thread Start: Thread ID: 592. Process SASPlanet.exe (220)
Thread Start: Thread ID: 660. Process SASPlanet.exe (220)
Thread Exit: Thread ID: 660. Process SASPlanet.exe (220)
Thread Exit: Thread ID: 592. Process SASPlanet.exe (220)
Thread Exit: Thread ID: 460. Process SASPlanet.exe (220)
Thread Exit: Thread ID: 1640. Process SASPlanet.exe (220)
Thread Exit: Thread ID: 296. Process SASPlanet.exe (220)
Thread Exit: Thread ID: 476. Process SASPlanet.exe (220)
Thread Exit: Thread ID: 1012. Process SASPlanet.exe (220)
Thread Start: Thread ID: 292. Process SASPlanet.exe (220)
Thread Start: Thread ID: 1936. Process SASPlanet.exe (220)
Thread Start: Thread ID: 224. Process SASPlanet.exe (220)
Thread Start: Thread ID: 416. Process SASPlanet.exe (220)
Thread Start: Thread ID: 420. Process SASPlanet.exe (220)
Thread Start: Thread ID: 364. Process SASPlanet.exe (220)
Thread Start: Thread ID: 424. Process SASPlanet.exe (220)
Thread Start: Thread ID: 396. Process SASPlanet.exe (220)
Thread Start: Thread ID: 908. Process SASPlanet.exe (220)
Thread Exit: Thread ID: 364. Process SASPlanet.exe (220)
Thread Exit: Thread ID: 224. Process SASPlanet.exe (220)
Thread Exit: Thread ID: 420. Process SASPlanet.exe (220)
Thread Exit: Thread ID: 416. Process SASPlanet.exe (220)
Thread Exit: Thread ID: 424. Process SASPlanet.exe (220)
Thread Start: Thread ID: 1624. Process SASPlanet.exe (220)
Thread Start: Thread ID: 1840. Process SASPlanet.exe (220)
Thread Start: Thread ID: 1696. Process SASPlanet.exe (220)
Thread Start: Thread ID: 1856. Process SASPlanet.exe (220)
Thread Start: Thread ID: 592. Process SASPlanet.exe (220)
Thread Exit: Thread ID: 1624. Process SASPlanet.exe (220)
Thread Start: Thread ID: 660. Process SASPlanet.exe (220)
Thread Exit: Thread ID: 1856. Process SASPlanet.exe (220)
Thread Exit: Thread ID: 1840. Process SASPlanet.exe (220)
Thread Start: Thread ID: 1468. Process SASPlanet.exe (220)
Thread Start: Thread ID: 1152. Process SASPlanet.exe (220)
Thread Start: Thread ID: 1640. Process SASPlanet.exe (220)
Thread Exit: Thread ID: 1696. Process SASPlanet.exe (220)
Thread Exit: Thread ID: 592. Process SASPlanet.exe (220)
-------------------- |
|
|
|
(0009232)
|
|
zed
|
07-10-2012 09:43
(edited on: 07-10-2012 09:44) |
|
Останови все рабочие закачки кроме зависшего (позакрывай окошки). И минут с 10 выжди. А потом посмотри в список активных потоков. Все TTileRequestQueueProcessorThread должны закрыться по тайм-ауту.
|
|
|
|
(0009234)
|
|
Parasite
|
07-10-2012 10:03
(edited on: 07-10-2012 10:05) |
|
Держи:
4. Скрин проги
5. Скрин тредов
|
|
|
|
(0009235)
|
|
zed
|
|
07-10-2012 10:15
|
|
Ага, значит качалка ни при чём.
Попробуй поснаставить брекпоинтов в юните RegionProcess/u_ThreadDownloadTiles в процедуре procedure TThreadDownloadTiles.Execute; (только окошки живых закачек закрой). Если поток живой и что-то робит, то должен сработать брекпоинт.
Чтобы поставить брекпоинт просто кликни по синенькому кружочку слева возле номера строки в юните. |
|
|
|
(0009236)
|
|
zed
|
|
07-10-2012 10:18
|
|
Offtop:
Кстати, в этой же процедуре, можешь затестить и соседний баг 0001592 - долгий расчёт происходит в строке 532: VTileIterator := TTileIteratorByPolygon.Create(FPolyProjected); |
|
|
|
|
Держи:
6. Скрин проги
7. Скрин отладчика.
10мин - ничего не происходит. Стоим-ссс..... |
|
|
|
(0009238)
|
|
zed
|
|
07-10-2012 10:32
|
|
|
Ты поставил только один брекпоинт. А нужно поставить в каждой (!) строке в этой процедуре. |
|
|
|
|
>нужно поставить в каждой (!) строке в этой процедуре.
Охх, щщи...
Щас сделаю. |
|
|
|
|
Покликал в везде на строках 528...658 (включительно). Скрин не привожу.
Ничего не происходит. |
|
|
|
|
Все еще ничего.
Как стояли в треде, так и стоим. Брейкпоинты не срабатывают. Изменилось только прогнозируемое время отработки треда (66 дней, 13 часов).
Предлагаю перейти в аську для оперативности. |
|
|
|
(0009248)
|
|
zed
|
|
07-10-2012 10:55
|
|
|
Да как бы на этом всё. Он где-то висит уже. В одной из этих строк. |
|
|
|
|
|
Есть в делфе такая кнопочка "Pause", которая останавливает все потоки. А потом переключаешься с потока на поток и смотришь стеки. На чем какой стоит. |
|
|
|
|
И я тебе и без этого скажу на чем оно стоит. На строчке:
FFinishEvent.WaitFor(INFINITE);
А вот почему не прилетело уведомление об окончании обработки запроса или ошибке при его обработке я не знаю. |
|
|
|
|
>А вот почему не прилетело уведомление об окончании обработки запроса или ошибке при его обработке я не знаю.
Канал сегодня был забит на >98%, и была куча таймаутов и без саса. Подозреваю, что какой-то из потоков просто не отбился виндой по таймауту, и так и висит до сих пор.
Но на проксике открытых сокетов нет ни в одном из статусов. Может ли быть так, что САС пытался закрыть\прервать сокет раньше, чем его закрыла система (через что словил сокетовый аналог "Sharing Violation" и задумался), а потом система его закрыла по таймауту - а САС все еще в раздумьях и не перевосстанавливает попытки? |
|
|
|
(0009256)
|
|
zed
|
|
07-10-2012 11:26
|
|
>И я тебе и без этого скажу на чем оно стоит.
И что ж ты так долго молчал :)
Ну, даже если оно и зависло на каком-то тайле, то не выясняя причину "виса" можно же этот участок обработать не через INFINITE, а поставить ему тайм-аут. И пробовать ехать дальше? |
|
|
|
|
|
Оно то можно. Но это не выход. Точно так же могут отваливаться закачки по видимой области, а там это не прокатит, там семафор количество активных считает, а это значит, что постепенно будет уменьшаться количество закачиваемых тайлов, пока вообще не перестанет качать. |
|
|
|
|
>это не выход
На самом деле именно это и выход. А семафор надо пописать, чтобы он этот факт учитывал. |
|
|
|
(0009270)
|
|
vdemidov
|
07-10-2012 20:11
(edited on: 07-10-2012 20:13) |
|
> А семафор надо пописать, чтобы он этот факт учитывал.
Как он это может учитывать? Нет, нужно поймать, как оно вообще может вылететь без уведомления ITileRequestTask.FinishNotifier
|
|
|
|
|
|
Совершенно обычным способом он это может учитывать. Или я вопрос не понимаю. С точки зрения семафора совершенно неважно, по ошибке HTTP вылет или по таймауту (не INFINITE). Просто надо либо свалить оттудова потом, либо снова зайти за скачкой. |
|
|
|
|
|
Нету нигде таймаута после захвата семафора. Смотри, семафор захвачен 4 раза. Но вернуло оно только 3 раза потому что один потерялся так же как теряется сейчас при закачке. И все. Он уже не вернется. Следующий раз запустится только 3 треда. Из которых может вернуться уже только 2. И так далее. Таймаут спасет нас только от зависания, но не поможет запустить закачку заново. |
|
|
|
|
|
Нашел я одно очень подозрительное место, которое могло при таймаутах вызывать пропадание запроса. Проверишь в завтрашней ночнушке. |
|
|
|
|
>Нашел я одно очень подозрительное место, которое могло при таймаутах вызывать пропадание запроса. Проверишь в завтрашней ночнушке.
Отлично. Подождем. |
|
|
|
(0009298)
|
|
zed
|
|
08-10-2012 14:04
|
|
|
А чё ждать-то? Прикрепил exe. Тестируй. |
|
|
|
|
>Прикрепил exe. Тестируй.
Ага, спасибо. Качаю, поставлю на ночь под сильную загрузку. С утра и посмотрим... |
|
|
|
(0009431)
|
|
zed
|
|
09-10-2012 17:07
|
|
|
Можешь даже 2-3 экземпляра поставить. Нехай друг-другу конкуренцию создают :) |
|
|
|
|
Утро, день первый: ни один из 8и потоков пока не завис. И вроде как качать\сохранять в кэш стало визуально пошустрее (в каждом потоке) - тайлы сыпятся пачками по 5-10 судя по счетчику, тогда как раньше - по 2-3. Но можетэто просто у меня канал пустой, в кои-то веки. Но пока что положительно.
Если до завтра не зависнет - можно будет говорить о том, что таки вылечилось... |
|
|
|
|
|
|
|
|
2 из 8и тредов зависли в обычном порядке. :(
Еще и AVшка вылезла ни с того ни с сего (но приложение не закрылось. После нажатия на ОК - работает вроде). |
|
|
|
(0009469)
|
|
zed
|
|
10-10-2012 12:17
|
|
>Еще и AVшка вылезла ни с того ни с сего
Давай лог. |
|
|
|
|
|
|
|
(0009482)
|
|
zed
|
10-10-2012 16:17
(edited on: 10-10-2012 16:24) |
|
О как, т.е. при попытке взять тайл из очереди, произошла ошибка, в результате чего скорее всего вылетел TTileRequestQueueProcessorThread вместе со всей очередью. И два треда остались не у дел - запрос отдали, а ответить уже некому...
Если всё так, то пока не будет новых AV потоки должны работать нормально.
|
|
|
|
|
|
Не. Вылет TTileRequestQueueProcessorThread больше ни на что не влияет. Очередь живет своей жизнью независимо. |
|
|
|
|
|
А вот что случилось с очередью непонятно. |
|
|
|
(0009485)
|
|
zed
|
|
10-10-2012 16:35
|
|
|
C потокобезопасностью там всё впорядке? |
|
|
|
|
|
Проверяйте. Я думаю, что должно быть в порядке, но может где-то ошибся. |
|
|
|
|
Перезапустил эти два потока. Работает пока что (после AV не вылетал\не перезапускался, просто съеррорил и работает себе дальше).
Оставлю на ночь, если будут какие новости\новые зависоны - сообщу. |
|
|
|
(0009494)
|
|
zed
|
|
10-10-2012 17:32
|
|
Во-первых, мне кажется, что возможно переполнение счётчиков FTailIndex и FHeadIndex (оба integer). Наврят ли именно в этом дело, но чисто теоретически они таки в конце-концов станут отрицательными и появится ошибка out of bounds при обращении к FRequestArray.
Во-вторых, по-моему, всё-таки проблема с синхронизацией потоков, т.е. теоретически возможна ситуация, когда поток А увеличил счётчик очереди (FTailIndex=1), но не успел записать запрос в условную ячейку 1 в FRequestArray и очень долго спит, а поток B увеличил счётчик (FTailIndex=2), поставил запрос в условную ячейку 2 и разрешил семафор FReadyRequestSemaphore. Тогда, кто-то может попытаться взять из очереди запрос (FHeadIndex=1) из ячейки 1 - то, что должно было быть записано потоком A, но тот всё ещё спит, и там голый nil...
Т.е. у тебя используются потокобезопасные счётчики и ты исключил ситуацию одновременной записи запросов в одну и ту же ячейку в FRequestArray, да вот только не синхронизированы запись и чтение из одной и той же ячейки. Если я правильно понимаю. |
|
|
|
|
|
Да. Ты прав. Именно это и произошло в данном случае. Потому и два потока закачки отвалились. Потому что два задания на закачку были забыты. |
|
|
|
|
|
|
|
|
|
Плотно потестировать уже не предлагаешь? :) |
|
|
|
|
|
Теперь я уже почти на 100% уверен. Но ты тестируй. В любом случае если что-то и вылезет это будет новая бага и в другом месте. |
|
|
|
(0009514)
|
|
Parasite
|
12-10-2012 06:06
(edited on: 12-10-2012 06:09) |
|
>почти на 100% уверен. Но ты тестируй
Докладуюсь:
Предыдудая zed'ова конструкция больше по потокам не зависала после вышеописанного AV. Работает как и должна.
Скачал последнюю ночнушку.
Сохранил все идущие закачки в .sls.
Вышел из zed'овой версии. Тут же вылетел AV "Memory Leak". Файл .elf не создался, но приложение закрылось согласно ожидаемого - ну и х бы с ним.
Запустил последнюю ночнушку.
Попытался потестить путем старта закачки с сохраненных ранее .sls.
Тут же моментально получил AV.
В итоге - потестить нет возможности, при попытке восстановления любой закачки вылазит AV и даже окошечко треда не успевает открыться.
Файл .elf прилагаю.
|
|
|
|
|
|
Это совсем другой баг, не имеющий никакого отношения к старому. |
|
|
|
|
|
SASPlanet.Debug.Bug.1264.elf (43,516) 10-10-2012 15:44