Tcl Source Code

zlib.test
---- zlib-12.2 start
==308== Syscall param write(buf) points to uninitialised byte(s)
==308==    at 0x525B420: __write_nocancel (syscall-template.S:81)
==308==    by 0x596BFD: FileOutputProc (tclUnixChan.c:302)
==308==    by 0x527FA4: ChanWrite (tclIO.c:517)
==308==    by 0x52BAFE: Tcl_WriteRaw (tclIO.c:4039)
==308==    by 0x595341: ZlibTransformOutput (tclZlib.c:3134)
==308==    by 0x527FA4: ChanWrite (tclIO.c:517)
==308==    by 0x52A274: FlushChannel (tclIO.c:2747)
==308==    by 0x532F37: MBWrite (tclIO.c:9354)
==308==  Address 0xd5f43e5 is 21 bytes inside a block of size 4,096 alloc'd
==308==    at 0x4C27BE3: malloc (vg_replace_malloc.c:299)
==308==    by 0x5D1062: TclpAlloc (tclAlloc.c:699)
==308==    by 0x43C1F0: Tcl_Alloc (tclCkalloc.c:1059)
==308==    by 0x596322: ZlibStackChannelTransform (tclZlib.c:3672)
==308==    by 0x593E82: ZlibPushSubcmd (tclZlib.c:2491)
==308==    by 0x593497: ZlibCmd (tclZlib.c:2158)
==308==    by 0x42FB95: Dispatch (tclBasic.c:4357)
==308==    by 0x42FC1D: TclNRRunCallbacks (tclBasic.c:4390)
==308== 
++++ zlib-12.2 PASSED

Fix applied. A deep problem was that zlib-12.2 was very wrong anyway, which was stopping us from noticing that the tested code was failing. The Z_BUF_ERROR result shouldn't be produced in the decompressing loop, as we don't feed in zero length input (as this is a non-flushing use case) or use a zero length output buffer, so the code actually becomes simpler and less twisty. Which is nice.

fossil coordinates?  I can't find this with valgrind or asan on core-8-6-branch or core-8-6-7-rc.

This is a new failure in 8.6.7.
I don't want to release it unless
an expert tells me that fixing it
is really infeasible in a short term.

I see where the problem is in ZlibTransformOutput()
but I don't have the knowledge to know how
to fix.

alert dkf in case it's obvious to him before
I can figure it out.