[Zlib-devel] Compressing volatile data?

[Gary Cameron]

Hi, I was wondering if somebody on this list could answer a question 
about a rather unusual application for the zlib libraries:

Background:
I am using zlib to compress huge multi-GB core files, which are 
generated when a fatal runtime error has occurred, and have encountered 
occasional decompression failures.

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?

For example, if you had a multi threaded application and one thread was 
compressing a buffer while the other thread was still writing to parts 
of it, could a race condition happen within the zlib compression 
algorithm that would result in bad compression data that could not be 
decompressed?  Obviously the volatile bits of memory that was active at 
the time of compression may be in an indeterminate state when 
decompressed, but I am more interested in knowing if this scenario could 
result in a completely trashed and unusable compress buffer.

If this is likely, I may have to copy the RAM into a dedicated buffer a 
chunk at a time to guarantee that it doesn't change state during the 
compression.

Thanks in advance!