ZLIB в Windows: gzopen / gzwrite / gzclose создает кастрированный выходной файл / антивирус по ошибке?

Question

Я уже несколько дней гонюсь за очень загадочной ошибкой, которая, кажется, вращается вокруг ( библиотеки ZLIB ); это происходит один раз в месяц или около того, и только в некоторых конкретных производственных средах. Вот что делает код:

1. Программа вызывает gzopen для записи в файл X.
2. Программа записывает данные в файл, делая несколько gzwrite.
3. Программа наконец вызывает gzclose, который очищает файл.

Обычно все отлично работает, и файл X действителен; он правильно завершается с помощью CRC и длины исходного потока.

Однако, в одном из сбоев, я наблюдаю, что X поврежден: начало данных правильное, но начиная со смещения 0x00302000, каждый байт равен нулю. Даже восемь последних байтов, которые кодируют CRC и длину, равны нулю. Тем не менее, файл имеет правильный размер! И что еще хуже: та же система успешно сжала очень похожий файл несколькими минутами ранее.

Примечание. Используемая нами ZLIB.DLL имеет версию 1.1.3; да, я знаю, он содержит некоторые дыры в безопасности, и мы должны обновить его до последней версии ZLIB 1.2.3, но я не хочу ничего менять в моей настройке, пока не найду причину обнуления.

Я думаю, что я исключил повреждение памяти (кстати, как может поврежденная куча памяти мешать fwrite в достаточной степени, чтобы она только записывала нули в выходной поток? Это было бы правдоподобно?), Цикл, который открывается / write / закрывает поток просто и не обнаруживает никаких дефектов, которые я могу обнаружить, код не распределяет / освобождает / не связывается со структурами в ZLIB (что может быть проблемой, поскольку ZLIB связан с другой библиотекой C, чем мои прикладные DLL ), поэтому я могу подозревать только другие элементы в системе.

Почему-то я склонен доверять библиотеке C (CRTDLL.DLL), Win32 API, стеку NTFS, стеку ввода-вывода, низкоуровневым драйверам устройств, прошивке жестких дисков и самим жестким дискам. ... И да, я также склонен полагать, что Visual C ++ 2008 производит правильные двоичные файлы, по крайней мере, в этом случае; -)

Итак, я прав, подозревая, что антивирусное программное обеспечение может быть виновником? С ZLIB следует быть осторожным, так как по крайней мере Касперский признает DLL как возможную угрозу. Но было бы политически правильно, чтобы антивирус просто записывал нули вместо данных, если инфекция (неправильно) обнаружена? Или это может быть ошибка в антивирусе?

Или я полностью упускаю суть?

Answer 1

Не зная ничего другого, я бы заподозрил ваш код, а не антивирусный код.

Требуется простая ошибка, чтобы записать правильную длину данных в файл, но передать в неправильный буфер, что приведет к появлению «всех нулей» в качестве данных в файле.

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

Если бы я устранял это, я бы:

• упрощение упрощение упрощение, пока проблема не остановится. затем добавьте сложность обратно, пошагово.
• проверьте ваши указатели и арифметику указателей
• проверьте, правильно ли вы очищаете и закрываете файл
• использовать распределитель, который сохраняет байты маркера в выделенных буферах, например, 0xAA, а не 0x00. Таким образом, вы можете увидеть, является ли ваш (обнуленный) буфер записываемым в файл.
• пройти через все это в отладчике

В нормальных условиях данные GZIP никогда не будут иметь длинную последовательность нулей. Они будут свернуты в словарь и код длины.