ZLIB på Windows: gzopen/gzwrite/gzclose producerer castrated output fil/antivirus ved fejl?

Indlæg af Hanne Mølgaard Plasc

Problem



Jeg har jaget en meget mystisk bug i dagevis, som synes at dreje rundt om (ZLIB-biblioteket), det sker en gang om måneden eller så og kun på nogle specifikke produktionsmiljøer. Her er hvad koden gør: [9]



  1. Programmet kalder gzopen for at skrive til en fil X.

  2. Programmet skriver data til filen, gør flere gzwrite.

  3. Programmet kalder endelig gzclose, der spilder filen.



Normalt fungerer alt fint, og filen X er gyldig; den er korrekt afsluttet med CRC og længden af ​​kildestrømmen.


I en af ​​fejlene bemærker jeg imidlertid, at X er korrupt: begyndelsen af ​​dataene er korrekt, men starter ved forskydning 0x00302000 er hver byte null. Selv de otte sidste byte, som koder for CRC og længden, er nul. Filen har dog den rigtige størrelse! Og hvad der er værre: det samme system komprimerede med succes en meget lignende fil et par minutter tidligere.


Bemærk: Den ZLIB.DLL, vi bruger, har version 1.1.3; Ja, jeg ved, det indeholder nogle sikkerhedshuller, og vi skal opgradere til den nyeste ZLIB 1.2.3, men jeg ønsker ikke at ændre noget i mit setup, før jeg har fundet årsagen til nulstillingen.


Jeg tror, ​​at jeg har udelukket hukommelseskorruption (forresten, hvordan kan en korrupt hukommelseshunge forstyrre fwrite tilstrækkeligt, at den kun skriver nuller til udgangsstrømmen? Ville det være plausibelt?), Den sløjfe, der åbner/skriver/lukker strømmen er enkel og afslører ikke nogen defekter, jeg kan se, koden tildeler ikke/fri/rod med strukturer i ZLIB (hvilket kunne være et problem, da ZLIB er linket til et andet C-bibliotek end mine ansøgnings-DLL'er) , så jeg kan kun mistænke andre elementer i systemet.


På en eller anden måde har jeg tendens til at have tillid til C-biblioteket (CRTDLL.DLL), Win32 API, NTFS-stakken, I/O-stakken, de lavtliggende enhedsdrivere, harddiskenes harddisk og harddisken selv ... Og ja, jeg har også en tendens til at tro, at Visual C ++ 2008 producerer korrekte binære filer, i det mindste i dette tilfælde ;-)


Så har jeg ret til at mistanke om, at antivirusprogrammet kunne være synderen? Det skal være forsigtigt med ZLIB, da Kaspersky i det mindste anerkender DLL som en mulig trussel. Men ville det være politisk korrekt for et antivirus at blot skrive nuller i stedet for dataene, hvis en infektion er (forkert) spottet? Eller kan det være en fejl i antivirusprogrammet?


Eller savner jeg helt det punkt?

Bedste reference


Uden at vide noget andet, vil jeg mistanke om din kode, snarere end antiviruskode.


Det ville kræve en simpel fejl at skrive den korrekte længde af data til filen, men passerer i en forkert buffer, hvilket resulterer i 'alle nuller' som data i filen.


Enkle fejl, der er svære at plette, fører nogle gange til meget stor forvirring, som du har.


Hvis jeg fejlfindte dette ville jeg:



  • Forenkle forenkle forenkle, indtil problemet er stoppet. Tilføj derefter kompleksitet tilbage i trinvis.

  • Kontroller dine peger og pointer aritmetik

  • Kontroller, at du spyler & Lukning af filen korrekt

  • Brug en tildeler, der gemmer markørbyte i de tildelte buffere, ligesom 0xAA i stedet for 0x00. På denne måde kan du se, om det er din (nulstillet) buffer, der skrives til filen.

  • Træd gennem det hele i en debugger



Under normale omstændigheder vil GZIP 'd data aldrig have en looong-rækkefølge af nuller. Disse vil blive kollapset i en ordbog og længdekode.