#166 memory leak: "fortran.c"

open
nobody
None
5
2007-06-02
2007-06-02
Elliott Hughes
No

helium:~/Projects/ctags/trunk$ valgrind --leak-check=full --show-reachable=yes ./dctags -nu -o tags.test Test/*
==28078== Memcheck, a memory error detector.
==28078== Copyright (C) 2002-2006, and GNU GPL'd, by Julian Seward et al.
==28078== Using LibVEX rev 1658, a library for dynamic binary translation.
==28078== Copyright (C) 2004-2006, and GNU GPL'd, by OpenWorks LLP.
==28078== Using valgrind-3.2.1-Debian, a dynamic binary instrumentation framework.
==28078== Copyright (C) 2000-2006, and GNU GPL'd, by Julian Seward et al.
==28078== For more details, rerun with: -v
==28078==
==28078==
==28078== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 13 from 1)
==28078== malloc/free: in use at exit: 548 bytes in 17 blocks.
==28078== malloc/free: 35,003 allocs, 34,986 frees, 1,491,094 bytes allocated.
==28078== For counts of detected errors, rerun with: -v
==28078== searching for pointers to 17 not-freed blocks.
==28078== checked 68,072 bytes.
==28078==
==28078== 36 bytes in 1 blocks are definitely lost in loss record 1 of 2
==28078== at 0x4021620: malloc (vg_replace_malloc.c:149)
==28078== by 0x806347E: eMalloc (routines.c:238)
==28078== by 0x805429B: newToken (fortran.c:414)
==28078== by 0x8056356: parseInterfaceBlock (fortran.c:1725)
==28078== by 0x805661D: parseDeclarationConstruct (fortran.c:1834)
==28078== by 0x805679F: parseSpecificationPart (fortran.c:1901)
==28078== by 0x80569F5: parseModule (fortran.c:1990)
==28078== by 0x8056E05: parseProgramUnit (fortran.c:2142)
==28078== by 0x8056F37: findFortranTags (fortran.c:2183)
==28078== by 0x806077A: createTagsForFile (parse.c:617)
==28078== by 0x8060810: createTagsWithFallback (parse.c:637)
==28078== by 0x80608DC: parseFile (parse.c:664)
==28078==
==28078==
==28078== 512 bytes in 16 blocks are still reachable in loss record 2 of 2
==28078== at 0x4021620: malloc (vg_replace_malloc.c:149)
==28078== by 0x806347E: eMalloc (routines.c:238)
==28078== by 0x806AF16: vStringNew (vstring.c:116)
==28078== by 0x80542C0: newToken (fortran.c:419)
==28078== by 0x8054309: newTokenFrom (fortran.c:429)
==28078== by 0x80562E5: parseInterfaceBlock (fortran.c:1709)
==28078== by 0x805661D: parseDeclarationConstruct (fortran.c:1834)
==28078== by 0x805679F: parseSpecificationPart (fortran.c:1901)
==28078== by 0x80569F5: parseModule (fortran.c:1990)
==28078== by 0x8056E05: parseProgramUnit (fortran.c:2142)
==28078== by 0x8056F37: findFortranTags (fortran.c:2183)
==28078== by 0x806077A: createTagsForFile (parse.c:617)
==28078==
==28078== LEAK SUMMARY:
==28078== definitely lost: 36 bytes in 1 blocks.
==28078== possibly lost: 0 bytes in 0 blocks.
==28078== still reachable: 512 bytes in 16 blocks.
==28078== suppressed: 0 bytes in 0 blocks.

looks to be the same longjmp(3) root cause as the "sql.c" leak, but there are a lot more calls to newToken here, suggesting that we perhaps want a more automated solution.

Discussion