bug in zlib binding makes cabal-install segfault

[guest]

Using the newest library version on hackage, "cabal update" segfaults after downloading the package list from hackage. "cabal install" produces the error "cabal: Data.ByteString?.Lazy.index: index too large: 0"

steps to reproduce the problem (at least for me): install the newest versions of Cabal (1.2.2.0), HTTP (3001.0.0), and zlib (0.4.0.1) from hackage, compile and install cabal-install (0.4.0) from hackage, create a directory called dist (to circumvent another problem with cabal-install), run cabal update, or cabal install

os: Linux
arch: i686
ghc: 6.6
zlib: 1.1.4

Here are the last lines of the output of "ltrace cabal update":

open64("/home/doserj/.cabal/packages/hac"..., 2369, 0666) = 4
__fxstat64(3, 4, 0x909108)                = 0
fcntl(4, 3, 0x909108, 1, 0x900060)        = 34817
fcntl(4, 4, 34817, 1, 0x900060)           = 0
__fxstat64(3, 4, 0xbfff8c90)              = 0
isatty(4)                                 = 0
ftruncate64(4, 0, 0, 0, 0)                = 0
malloc(56)                                = 0x875aa30
inflateInit2_(0x875aa30, 31, 0x8285868, 56, 0) = -2
--- SIGSEGV (Segmentation fault) ---
+++ killed by SIGSEGV +++

[duncan]

Thanks, so it's clearly a bug in the zlib binding. For one thing we should not be calling inflateInit2 in such a way that it returns an error code and secondly in the situation that it does return an error we should raise an exception and not segfault.

So this will require a bit of work, debugging with that version of zlib. As a workaround, you could modify the zlib.cabal package description to always use the bundled zlib-1.2.3 code rather than using the system zlib. Currently it only uses the bundled version on windows. In fact that would be an interesting experiment.

My guess is that the behavior is slightly different between the zlib 1.1 and 1.2 series, though obviously it would be good if the zlib binding could work with both versions if that version is still widely deployed.

[duncan]

I think I've found the bug. I think it was caused by a change between zlib-1.1.x and 1.2.x but it was also my fault for not being sufficiently careful with error handling.

My guess is that in zlib-1.1.x, functions like inflateInit can return error codes without setting the string error message msg. The zlib binding code was always looking at the msg member of the z_stream structure and trying to read a string error message from it. If the msg member was NULL then this would produce the behavior in the ltrace output above. So I've changed the error handling code to check if the msg is NULL before inspecting its contents.

This should fix the segfault but it does not explain why inflateInit2 was returning Z_STREAM_ERROR. The documentation says it can return Z_STREAM_ERROR "if a parameter is invalid (such as a negative memLevel)" but I cannot see what it is talking about since memLevel is a parameter to deflateInit not inflateInit.

I've uploaded zlib-0.4.0.3  http://hackage.haskell.org/cgi-bin/hackage-scripts/package/zlib-0.4.0.3

So I'm closing because I think the segfault is fixed. If you can still get a problem where decompressing the index file fails then re-open or file a new bug.

[elga]

*  virgin mobile