<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
I was speaking with our local architect about this issue -<br>
<br>
Obviously if there is still any "live" memory that is being compressed
it is a bug on our end that we need to track down, although f it
results in errors that are
undetectable until you try to decompress it becomes rather nasty.<br>
<br>
Your proposed zmemcpy fix is a great safety feature that should
probably be enabled by default, although he was concerned if there
would be an unnecessary performance hit from the extra copy if you
could guarantee the source data was static. If fixing this will
involve a performance impact, he suggested making it a compile time
option you could switch off. For those who don't mind living
dangerously and have the need for speed...<br>
<br>
<br>
<a class="moz-txt-link-abbreviated" href="mailto:glennrp@comcast.net">glennrp@comcast.net</a> wrote:
<blockquote
cite="mid:836683787.984616.1283525621212.JavaMail.root@sz0023a.westchester.pa.mail.comcast.net"
type="cite">
<pre wrap="">----- Original Message -----
From: "Mark Adler" <a class="moz-txt-link-rfc2396E" href="mailto:madler@madler.net"><madler@madler.net></a>
To: <a class="moz-txt-link-abbreviated" href="mailto:zlib-devel@madler.net">zlib-devel@madler.net</a>
Sent: Friday, September 3, 2010 12:44:33 AM
Subject: Re: [Zlib-devel] Compressing volatile data?
On Sep 2, 2010, at 11:03 AM, Gary Cameron wrote:
</pre>
<blockquote type="cite">
<pre wrap="">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?
</pre>
</blockquote>
<pre wrap=""><!---->
Gary,
Yes.
This code in deflate.c is the only thing that accesses the source buffer:
if (strm->state->wrap == 1) {
strm->adler = adler32(strm->adler, strm->next_in, len);
}
else if (strm->state->wrap == 2) {
strm->adler = crc32(strm->adler, strm->next_in, len);
}
zmemcpy(buf, strm->next_in, len);
So the buffer is accessed twice: first to compute a check value, and second to copy the data. If the source buffer is changed between those two, then the check value will not match the data, and an error will be reported when decompressing.
When this happens, the compressed data is not itself corrupted. The only problem is a mismatch between an earlier check value and later data.
This deflate sensitivity to volatile input data can be solved thusly:
zmemcpy(buf, strm->next_in, len);
if (strm->state->wrap == 1) {
strm->adler = adler32(strm->adler, buf, len);
}
else if (strm->state->wrap == 2) {
strm->adler = crc32(strm->adler, buf, len);
}
I have just made that change for the next version.
Mark
Don't you still hit the zmemcpy twice,
recreating the buf for each 'wrap'?
Glenn
_______________________________________________
Zlib-devel mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Zlib-devel@madler.net">Zlib-devel@madler.net</a>
<a class="moz-txt-link-freetext" href="http://mail.madler.net/mailman/listinfo/zlib-devel_madler.net">http://mail.madler.net/mailman/listinfo/zlib-devel_madler.net</a>
</pre>
</blockquote>
<br>
</body>
</html>