#2 deflateInit() memory allocation problem

[Anonymous]

Calling deflateInit() on machines with only 2Meg of
memory, results in a fatal error or other hard crash.
Depending on device, it looks like the screen memory
mapped area is getting over written with zero's.

Providing my own Alloc and Free functions prior to the
deflateInit() call, where myAlloc() raises a
SystemFatalException if it runs out of memory (the
suspected root cause), shows that the allocated
request for compression are about twice as I expected
to see from the provided documentation. The memory
requirements for decompression looked as expected.

E.G - decompression resulted in the following myAlloc
() calls:
item, size
1, 18
1, 52
4,1440
1,8192
296,2
19,2
288,2
1,20

However, the compression side looks goofy to me:
item, size
1, 4595
8192, 2
8192, 2
8192, 2
4096, 4
3, 14

For a total allocated request of 68K !!! Was expecting
a 38K hit.

For small footprint PalmOS devices, they run out of
memory room in my application during the third 8192x2
alloc().

Eh, shouldn't the size requests for the 8192 and 4096
items be 1 byte and *not* 2 bytes each?

I'm guessing that the default memory allocation
function gets back a null pointer and then uses it in
the following zmemset(), giving the reported error.

[Marc D. Chapman]

Logged In: YES
user_id=216629

First of all, sorry for the amount of time that this took to
respond. Were you using the latest patch that is out there
for zlib, or were you using the official release that is on
the page?

To me, this sounds like a problem that we ran into and fixed
with the patch, it is a problem with the allocation that
returns a Z_NULL and then the program crashes. The latest
patch (found in the patches section) solves this problem by
handling the Z_NULL properly.