Calling [zlib inflate] on malformed data from within tclkit-darwin-univ-aqua 8.4.16 causes the following crash:
tclkit(10940,0xa000d000) malloc: *** vm_allocate(size=1073745920) failed (error code=3) tclkit(10940,0xa000d000) malloc: *** error: can't allocate region tclkit(10940,0xa000d000) malloc: *** set a breakpoint in szone_error to debug unable to alloc 1073741832 bytes Abort trap
Since the zlib package is part of CritLib, maybe this should be filed as a CritLib issue.
This occurs when attempting to extract a truncated gzip file (first 18570 bytes of http://www.equi4.com/pub/tk/8.4.16/tclkit-linux-x86.gz, actually) with the first gunzip example procedure listed at http://wiki.tcl.tk/6175. I don't know if there's a way to validate the data in this case (by length, for example) before passing it to [zlib inflate], but should zlib be able to recover from this error anyway?
- 2008-01-05 Jim DeVona
Created
- 2008-01-06 jcw
I've never considered tclkit to be robust in the face of corrupt datafiles - likewise there are no doubt many cases where corruption in starkits will also lead to crashes. The only guarantee is that corrupt starkits cannot be created (even when the app is aborted), because the underlying Metakit file format uses transactions & commits. Since zlib is part of tclkit essentially to be able to deal with compressed starkits, I have always assumed that corrupt zlib input can not come from tclkit itself, only from outside causes such as aborted transfers - in which case it is really up to those outside mechanisms to guarantee correctness.
Is this position too harsh?
- 2008-01-06 Jim DeVona
No, your explanation is reasonable. Naturally, it would be nice if zlib could pull me out of trouble, but I am able to perform more validation of the data before passing it to zlib. This safeguards against the particular case I reported here.
- 2008-02-24 jcw
Marking this issue as resolved - tclkit/zlib are not properly set up to deal with damaged datafiles.