trunk/asm.c:
trunk/beta.c:
trunk/eiffel.c:
trunk/fortran.c:
trunk/jscript.c:
trunk/lregex.c:
trunk/main.c:
trunk/options.c:
trunk/pascal.c:
trunk/read.c:
trunk/routines.c:
trunk/routines.h:
trunk/sml.c:
trunk/sql.c: fix almost all our current memory leaks. Based on a patch from Dmitry Antipov, but also using his vString leak detector and valgrind(1) to find new ones and ones he missed. Three known leaks remain. The first is in parseLongOption. There's also one in "fortran.c" and another in "sql.c":
helium:~/Projects/ctags/trunk$ valgrind --leak-check=full --show-reachable=yes ./dctags -f - Test/*
==3056== Memcheck, a memory error detector.
==3056== Copyright (C) 2002-2006, and GNU GPL'd, by Julian Seward et al.
==3056== Using LibVEX rev 1658, a library for dynamic binary translation.
==3056== Copyright (C) 2004-2006, and GNU GPL'd, by OpenWorks LLP.
==3056== Using valgrind-3.2.1-Debian, a dynamic binary instrumentation framework.
==3056== Copyright (C) 2000-2006, and GNU GPL'd, by Julian Seward et al.
==3056== For more details, rerun with: -v
==3056==
.
.
.
==3056==
==3056== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 13 from 1)
==3056== malloc/free: in use at exit: 708 bytes in 22 blocks.
==3056== malloc/free: 36,126 allocs, 36,104 frees, 1,584,216 bytes allocated.
==3056== For counts of detected errors, rerun with: -v
==3056== searching for pointers to 22 not-freed blocks.
==3056== checked 68,184 bytes.
==3056==
==3056== 68 bytes in 2 blocks are definitely lost in loss record 1 of 2
==3056== at 0x4021620: malloc (vg_replace_malloc.c:149)
==3056== by 0x806347E: eMalloc (routines.c:238)
==3056== by 0x8065B68: newToken (sql.c:347)
==3056== by 0x80662BB: parseSubProgram (sql.c:688)
==3056== by 0x8067867: parseSqlFile (sql.c:1782)
==3056== by 0x8067934: findSqlTags (sql.c:1810)
==3056== by 0x8060760: createTagsForFile (parse.c:618)
==3056== by 0x8060810: createTagsWithFallback (parse.c:640)
==3056== by 0x80608DC: parseFile (parse.c:667)
==3056== by 0x805B7D6: createTagsForEntry (main.c:303)
==3056== by 0x805B811: createTagsForArgs (main.c:348)
==3056== by 0x805BD6F: makeTags (main.c:494)
==3056==
==3056==
==3056== 640 bytes in 20 blocks are still reachable in loss record 2 of 2
==3056== at 0x4021620: malloc (vg_replace_malloc.c:149)
==3056== by 0x806347E: eMalloc (routines.c:238)
==3056== by 0x806AEE2: vStringNew (vstring.c:116)
==3056== by 0x80542C0: newToken (fortran.c:419)
==3056== by 0x8054309: newTokenFrom (fortran.c:429)
==3056== by 0x80562E5: parseInterfaceBlock (fortran.c:1709)
==3056== by 0x805661D: parseDeclarationConstruct (fortran.c:1834)
==3056== by 0x805679F: parseSpecificationPart (fortran.c:1901)
==3056== by 0x80569F5: parseModule (fortran.c:1990)
==3056== by 0x8056E05: parseProgramUnit (fortran.c:2142)
==3056== by 0x8056F37: findFortranTags (fortran.c:2183)
==3056== by 0x806077A: createTagsForFile (parse.c:620)
==3056==
==3056== LEAK SUMMARY:
==3056== definitely lost: 68 bytes in 2 blocks.
==3056== possibly lost: 0 bytes in 0 blocks.
==3056== still reachable: 640 bytes in 20 blocks.
==3056== suppressed: 0 bytes in 0 blocks.
I think they're both awkward longjmp(3)/setjmp(3)-related leaks, and I don't currently have a good solution. ("eiffel.c" cunningly only calls newToken once, before calling setjmp(3).)
git-svn-id: svn://svn.code.sf.net/p/ctags/code/trunk@536 c5d04d22-be80-434c-894e-aa346cc9e8e8
elliotth
darren