Description: |
(text/x-fossil-wiki)
In core-8-branch, commit [ec5b3d21f9b29ee9], built with
<code>--enable-symbols CFLAGS=-DPURIFY</code>
, for zipfs-5.1 Valgrind reports:
<code><verbatim>
==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)
</verbatim></code>
The problem is that storage is allocated in <code>TclZipfs_MountBuffer</code>,
and the exit handler that cleans it up is established in
<code>ZipFSCatalogFilesystem</code>, but in some cases that routine returns
before establishing the exit handle.
|