digitalmars.D.bugs - [Issue 417] New: infinite loop in std.zlib.Compress.flush when passing Z_FULL_FLUSH
- d-bugmail puremagic.com (35/35) Oct 09 2006 http://d.puremagic.com/issues/show_bug.cgi?id=417
- d-bugmail puremagic.com (6/6) Oct 09 2006 http://d.puremagic.com/issues/show_bug.cgi?id=417
- d-bugmail puremagic.com (6/6) Oct 09 2006 http://d.puremagic.com/issues/show_bug.cgi?id=417
- d-bugmail puremagic.com (9/9) Oct 18 2006 http://d.puremagic.com/issues/show_bug.cgi?id=417
http://d.puremagic.com/issues/show_bug.cgi?id=417 Summary: infinite loop in std.zlib.Compress.flush when passing Z_FULL_FLUSH Product: D Version: 0.169 Platform: PC OS/Version: Windows Status: NEW Severity: normal Priority: P2 Component: Phobos AssignedTo: bugzilla digitalmars.com ReportedBy: lio lunesu.com The while loop at std/zlib.d line 358 never ended. Debugging revealed that deflate() returned Z_OK with zs.avail_out set to 4, but the zlib doc explicitely mentions: "... In the case of a Z_FULL_FLUSH or Z_SYNC_FLUSH, make sure that avail_out is greater than six to avoid repeated flush markers due to avail_out == 0 on return." std/zlib.d line 355: At the moment, the size of the allocated buffer can be anything. The easy fix is to reserve 6 bytes more, so we know we have room for more than 6 bytes (as required by zlib). This is zlib_avail_out_plus_6.patch: - tmpbuf = new void[zs.avail_out]; + tmpbuf = new void[zs.avail_out + 6]; Honestly, I don't see the relation between the zs.avail_out (set by a previous call to compress) and the buffer needed for deflate: zs.avail_out was the number of bytes _left unused_ in the output buffer after that previous call to deflate. It has no relation with the number of compressed bytes left. I suggest we use a fixed-size buffer, on the stack. This is zlib_ubyte_512.patch: - void[] tmpbuf; + ubyte[512] tmpbuf; - tmpbuf = new void[zs.avail_out]; --
Oct 09 2006
http://d.puremagic.com/issues/show_bug.cgi?id=417 Created an attachment (id=36) --> (http://d.puremagic.com/issues/attachment.cgi?id=36&action=view) Possible fix: reserve 6 bytes more --
Oct 09 2006
http://d.puremagic.com/issues/show_bug.cgi?id=417 Created an attachment (id=37) --> (http://d.puremagic.com/issues/attachment.cgi?id=37&action=view) Reserve 512 bytes on the stack --
Oct 09 2006
http://d.puremagic.com/issues/show_bug.cgi?id=417 bugzilla digitalmars.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED Incorporated in DMD 0.170 --
Oct 18 2006