www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 417] New: infinite loop in std.zlib.Compress.flush when passing Z_FULL_FLUSH

reply d-bugmail puremagic.com writes:
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:
#    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];


-- 
Oct 09 2006
next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=417





------- Comment #1 from lio lunesu.com  2006-10-09 11:48 -------
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
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=417





------- Comment #2 from lio lunesu.com  2006-10-09 11:49 -------
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
prev sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=417


bugzilla digitalmars.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED




------- Comment #3 from bugzilla digitalmars.com  2006-10-18 13:27 -------
Incorporated in DMD 0.170


-- 
Oct 18 2006