Bug 417 – infinite loop in std.zlib.Compress.flush when passing Z_FULL_FLUSH

Status
RESOLVED
Resolution
FIXED
Severity
normal
Priority
P2
Component
phobos
Product
D
Version
D1 (retired)
Platform
x86
OS
Windows
Creation time
2006-10-09T11:47:00Z
Last change time
2014-02-15T13:28:56Z
Assigned to
bugzilla
Creator
lio+bugzilla

Attachments

IDFilenameSummaryContent-TypeSize
36zlib_avail_out_plus_6.patchPossible fix: reserve 6 bytes moretext/plain425
37zlib_ubyte_512.patchReserve 512 bytes on the stacktext/plain515

Comments

Comment #0 by lio+bugzilla — 2006-10-09T11:47:05Z
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: # tmpbuf = new void[zs.avail_out]; 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];
Comment #1 by lio+bugzilla — 2006-10-09T11:48:29Z
Created attachment 36 Possible fix: reserve 6 bytes more
Comment #2 by lio+bugzilla — 2006-10-09T11:49:07Z
Created attachment 37 Reserve 512 bytes on the stack
Comment #3 by bugzilla — 2006-10-18T13:27:10Z
Incorporated in DMD 0.170