Tcl Source Code

In core-8-branch, commit [ec5b3d21f9b29ee9], built with --enable-symbols CFLAGS=-DPURIFY

, for zipfs-5.1 Valgrind reports:

==1880520== 0 bytes in 1 blocks are definitely lost in loss record 1 of 2
==1880520==    at 0x483E77F: malloc (vg_replace_malloc.c:307)
==1880520==    by 0x488C464: TclpAlloc (tclAlloc.c:699)
==1880520==    by 0x4A34BBB: TclZipfs_MountBuffer (tclZipfs.c:2096)
==1880520==    by 0x4A3520D: ZipFSMountBufferObjCmd (tclZipfs.c:2309)
==1880520==    by 0x4899194: Dispatch (tclBasic.c:4817)
==1880520==    by 0x489921A: TclNRRunCallbacks (tclBasic.c:4857)
==1880520==    by 0x4898ADC: Tcl_EvalObjv (tclBasic.c:4576)
==1880520==    by 0x489B1AF: TclEvalEx (tclBasic.c:5728)
==1880520==    by 0x49C5F82: Tcl_FSEvalFileEx (tclIOUtil.c:1782)
==1880520==    by 0x49D4A97: Tcl_MainEx (tclMain.c:399)
==1880520==    by 0x10A3B4: main (tclAppInit.c:91)

The problem is that storage is allocated in TclZipfs_MountBuffer, and the exit handler that cleans it up is established in ZipFSCatalogFilesystem, but in some cases that routine returns before establishing the exit handle.