[Zlib-devel] Compressing volatile data?

[Greg Roelofs]

> I was speculating on a possible cause - if parts of the data in the 
> source buffer being compressed is still "active" and changing during the 
> compression, could this cause a decompression failure?

If by "failure" you mean a CRC or Adler-32 check failure (and garbled
data), yes, that's entirely possible.  If you mean the inflater refuses
to process the remaining data, I'm not sure; that seems somewhat less
likely, but I could believe it's also possible.

I haven't looked at the deflater code in detail, but I believe it maintains
some sort of secondary data structure (beyond the sliding window/input buffer
itself) such as a hash table to keep track of previously compressed strings
(or perhaps even previously seen strings, for some definition of "seen").

The output data consists of "literals" (not interesting) and distance/length
pairs that tell the decoder there's another copy of a previously seen string
at a given location back in the buffer (the distance) and for a given number
of bytes (length).  Multiple distance/length pairs may refer to the same
general location in the buffer, so if that's changing at the same time,
you're going to end up with inconsistent output--perhaps simply a patchwork
of "snapshots" if my hypothetical hash table is used in an either/or fashion
with raw buffer lookups, or even single-string mashups if the table were
used to find candidate locations and then the raw buffer were checked for
the rest of the match.  Since the decoder's later output depends on both
the mixed-up compressed stream and its own earlier output (which is going
to be static, unlike the encoder's buffer), you'll see progressively worse
garbling the more you decode after the first mixed code.  And, of course,
any level of garbling at all is almost guaranteed to break the CRC-32.

I don't see how any of that would result in out-of-range codes (i.e.,
invalid encoder metadata), but I could easily be overlooking something.

Greg