Да х... его знает кем. Я что ли это писал

------------ Дoбавленo в 22.24:
Я уже написал, где, возможно, кроется баг. Проверить я это не смогу, по причине невозможности повторить такую "хитрую" ситуацию -- ну нет у меня ее, где мне ее взять А защиту на ZLIB, все таки, поставлю, лишним не будет

nesco, дочитай мое предыдущее сообщение до конца - я его редактировал.

Нулевая длина файла на выходе -- это 12 байт на входе перед распаковкой, а вот подай на вход 0 байт и получишь крэш.
Tad, ты невнимательно читаешь, что я пишу (или забываешь, просто), я писал про это уже и писал в чем проблема. И еще раз ее тут описал (гы)

Я тоже переименовывал этот файл, но у меня всё происходит именно так как описано в первом посте.

Последние размышлени на эту тему подсказали мне, что на выход распаковки подали файл, который не упакован ZLIB, и первые два байт содержат длину, большую, чем допустимый размер буфера памяти. ZLIB не распознает файлы "свой-чужой", и пытается его распаковать, а у него непомерная длина указана, естественно, получим Оut Of Memory
------------ Дoбавленo в 22.46:

Что, на обоих прогах, или только на штатном HiUpdate
------------ Дoбавленo в 22.58:
Самое интересное, что при переименнованном файле у меня что-то читает, и длина не равна 0, вот ZLIB и не плюется. Срочно надо поставить защиту от недопустимо малой длины
------------ Дoбавленo в 23.06:
olDjeka, обнови компонент ZLIB c SVN и проверь еще раз, если ничего читать не будет и не будет выдавать ошибку, то так и должно быть, тогда ищи у себя, почему нет доступа к серверу обновления

На обоих.


Обновил, но ничего не изменилось.


Доступ у меня есть. Ошибка возникла случайно, попробовал воспроизвести - получилось.
Расчитывая что результы кого-нибудь заинтересуют написал здесь.

Заинтересовало, но непонятно с чем это связано. Можно порекомендовать поставить Debug на выход HTTP_Get и посмотреть, что выдается у тебя, у меня там читается стрим вот с такими параметрами "stSize=7048, stPosition=0"

А такой вопрос -- у тебя весь пакет обновлен с SVN, или выборочно

Debug ставил, выдаёт stSize=256, stPosition=0
Обновлён полностью весь пакет SVN.
Возможно разница в результатах из-за железа? У меня P-III-650.

А железо-то тут причем Если только у тебя ОС не клон Win'98, вот тогда @опа


Тут читается явно что-то не то, что нужно, или не до конца, или вообще не оттуда, откуда надо. Ты уверен на все 100%, что этот файл читается именно с http://hiasm.com, а не откуда-нибудь из прокси буфера.

Я уже писал, что ZLIB тупой и ему по веникам, что пытаться разархивировать, а если это не его архив... Выводы делай сам

WinXPSP3.

Не то имел ввиду, "stSize=256, stPosition=0" выдаётся когда файл переименован, а когда нормальный, то "stSize=7048, stPosition=0".


Ясно, будем знать.

olDjeka, я в упор не могу понят -- ну кто может переименовать жестко зашитое имя файла Если не будет файла, то на выход попадет "пусто" и ZLIB дальше не пропустит.

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

Видимо, тогда ты попал на тот момент, когда Dilma обновлял файл списка, и его не было на сервере, а на ZLIB попал пустой стрим, и тот крэшнулся. Сейчас поставлена защита в ZLIB от пустых файлов, так что повторение такого маловероятно