#4823 Valgrind reports TCL memory leak

[judd gilbert]

Hello,

I am seeing a memory leak using Valgrind with C++ and TCL 8.6.b1. Here
is my example code:

#include <stdio.h>
#include <stdlib.h>
#include "tcl.h"

int main(int argc, char* argv[])
{
Tcl_Interp* MainInterp;
printf("creating interp...\n");
MainInterp = Tcl_CreateInterp();
printf("deleting interp...\n");
Tcl_DeleteInterp(MainInterp);
printf("finalizing...\n");
Tcl_Finalize();
printf("exiting...\n");
exit(0);

}

To compile I am doing the following:

../auxil/gcc-4.3.3/bin/g++ -I../auxil/tcl8.6b1/include src/
tcltest.cpp -ltcl8.6 -L../auxil/tcl8.6b1/lib

When running the output of this program using the Valgrind mem
checker :

valgrind --leak-check=full ./a.out

I get the following output:

==18208== Memcheck, a memory error detector
==18208== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et
al.
==18208== Using Valgrind-3.5.0 and LibVEX; rerun with -h for copyright
info
==18208== Command: ./a.out
==18208==
creating interp...
deleting interp...
finalizing...
exiting...
==18208== Invalid free() / delete / delete[]
==18208== at 0x400551D: free (vg_replace_malloc.c:325)
==18208== by 0x475C7D2D: ??? (in /lib/libc-2.5.so)
==18208== by 0x475C78A6: ??? (in /lib/libc-2.5.so)
==18208== by 0x40013B2: _vgnU_freeres (vg_preloaded.c:62)
==18208== by 0x475485A3: _Exit (in /lib/libc-2.5.so)
==18208== by 0x8048668: main (in /home/jgilbert/dev/src/tcs/a.out)
==18208== Address 0x4135b18 is not stack'd, malloc'd or (recently)
free'd
==18208==
==18208==
==18208== HEAP SUMMARY:
==18208== in use at exit: 14,400 bytes in 6 blocks
==18208== total heap usage: 2,190 allocs, 2,185 frees, 106,298 bytes
allocated
==18208==
==18208== 14,400 (2,400 direct, 12,000 indirect) bytes in 1 blocks are
definitely lost in loss record 6 of 6
==18208== at 0x4005903: malloc (vg_replace_malloc.c:195)
==18208== by 0x402ADAC: TclpAlloc (in /home/militho/dev/src/auxil/
tcl8.6b1/lib/libtcl8.6.so)
==18208== by 0x4038094: Tcl_Alloc (in /home/militho/dev/src/auxil/
tcl8.6b1/lib/libtcl8.6.so)
==18208== by 0x40B93FE: TclAllocateFreeObjects (in /home/militho/
dev/src/auxil/tcl8.6b1/lib/libtcl8.6.so)
==18208== by 0x40B9694: Tcl_NewObj (in /home/militho/dev/src/auxil/
tcl8.6b1/lib/libtcl8.6.so)
==18208== by 0x4032D4E: Tcl_CreateInterp (in /home/militho/dev/src/
auxil/tcl8.6b1/lib/libtcl8.6.so)
==18208== by 0x8048625: main (in /home/jgilbert/dev/src/tcs/a.out)
==18208==
==18208== LEAK SUMMARY:
==18208== definitely lost: 2,400 bytes in 1 blocks
==18208== indirectly lost: 12,000 bytes in 5 blocks
==18208== possibly lost: 0 bytes in 0 blocks
==18208== still reachable: 0 bytes in 0 blocks
==18208== suppressed: 0 bytes in 0 blocks
==18208==
==18208== For counts of detected and suppressed errors, rerun with: -v
==18208== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 25 from
10)

Some things I've noticed:

1. Without the call to Tcl_Finalize() I get even more errors.
2. If I change exit(0) to return(0) there is no change.
3. Simply linking with the TCL library causes the first message about
the invalid free/delete, with all code commented out except exit(0).

Has anyone else seen this? I'm wondering if this is a legitimate
memory leak in TCL 8.6b1. I searched bugs using the string "memory leak Tcl_CreateIterp" and found some similar bugs, but didn't see any solutions that really applied for me.

I am not sure this matters, but I am using RHEL kernel 2.6.18-8.el5 .

Thanks!

[Alexandre Ferrieux]

Sounds like a dup of 2919042.
Please confirm by applying the patch there.

[judd gilbert]

I agree it sounds like the same bug. I tried all 3 patches individually, none worked. Did a "make clean all install" between applying each one. Reversed changes in between applying each one. I still get the same error output.

[Alexandre Ferrieux]

Oops, sorry, HEAD had drifted by mundane things (comment layout, and (char *) casts in ckfree... sigh).
I have updated the patch there, please retry.
I think this will remove most of the leaks, but in my case a few remained. See my comment of 2009-12-22 15:24:52 CET in 2919042. If you observe similar things, please close the present bugreport and followup on the older one.

[judd gilbert]

Current patch val4.patch is busted I believe. I added all my notes about this to original bug 2919042