我几天来一直在追逐一个非常神秘的虫子，这似乎围绕着（ZLIB library）;它每个月左右发生一次，并且仅在某些特定的生产环境中发生。以下是代码的作用：
gzopen。X。gzwrite来刷新文件。通常，一切正常，文件gzclose有效;它以CRC和源流的长度正确终止。
但是，在其中一个失败中，我发现X已损坏：数据的开头是正确的，但从偏移X开始，每个字节都为空。即使编码CRC和长度的最后八个字节也是零。但是，文件大小合适！更糟糕的是：同一系统在几分钟前成功压缩了一个非常相似的文件。
注意：我们使用的ZLIB.DLL版本为1.1.3;是的，我知道，它包含一些安全漏洞，我们应该升级到最新的ZLIB 1.2.3，但我不想在我的设置中更改任何内容，直到我找到归零的原因。
我认为我已经排除了内存损坏（顺便说一句，腐败的内存堆如何能够充分地干扰0x00302000，它只会将零写入输出流？这是否合理？），循环打开/写入/关闭流是简单的，并没有揭示我可以发现的任何缺陷，代码不分配/释放/混乱ZLIB中的结构（这可能是一个问题，因为ZLIB链接到另一个C库而不是我的应用程序DLL），所以我只能怀疑系统中的其他元素。
不知何故，我倾向于对C库（CRTDLL.DLL），Win32 API，NTFS堆栈，I / O堆栈，低级设备驱动程序，硬盘固件和硬盘本身充满信心...是的，我也倾向于认为Visual C ++ 2008产生了正确的二进制文件，至少在这种情况下; - ）
那么，我怀疑防病毒软件可能是罪魁祸首吗？它应该对ZLIB持谨慎态度，因为至少卡巴斯基认为DLL是一种可能的威胁。但是，如果（错误地）发现感染，那么防病毒软件只是简单地写入零而不是数据，这在政治上是正确的吗？或者这可能是防病毒软件中的一个错误？
或者我完全忽略了这一点？
答案 0 :(得分：1)
在不知道其他任何事情的情况下，我会怀疑你的代码，而不是反病毒代码。
将正确长度的数据写入文件需要一个简单的错误，但是传入一个不正确的缓冲区，导致“全零”作为文件中的数据。
很难发现的简单错误有时会导致非常大的混乱，就像你一样。
如果我正在排除故障，我会：
在正常情况下，GZIP的数据永远不会有一连串的零。这些将折叠成字典和长度代码。