[jamming] Leaks in jam ?

[Alen Ladavac]

Hi Groleo,

AFAIU, Jam is architected as an "old-skool" Unix command line app. It
is ment to be ran once and do some processing. When it is done, it
relies on the CRT to free the entire memory pool. See e.g. from
newstr.c:

 * This implementation builds a hash table of all strings, so that multiple
 * calls of newstr() on the same string allocate memory for the string once.
 * Strings are never actually freed.

There's nothing wrong in this approach, because Jam exits after each
build is done.
 
Cheers,
Alen

Groleo wrote:

> I've seen alot of comments inside jam telling that some portions of
> memory is never freed.
> I went further and run jam through valgrind:

> ==16330== Memcheck, a memory error detector.
> ==16330== Copyright (C) 2002-2005, and GNU GPL'd, by Julian Seward et al.
> ==16330== Using LibVEX rev 1575, a library for dynamic binary translation.
> ==16330== Copyright (C) 2004-2005, and GNU GPL'd, by OpenWorks LLP.
> ==16330== Using valgrind-3.1.1-Debian, a dynamic binary
> instrumentation framework.
> ==16330== Copyright (C) 2000-2005, and GNU GPL'd, by Julian Seward et al.
> ==16330== For more details, rerun with: -v
> ==16330==
> --16330-- DWARF2 CFI reader: unhandled CFI instruction 0:50
> --16330-- DWARF2 CFI reader: unhandled CFI instruction 0:50
> ...found 224 target(s)...
> ==16330==
> ==16330== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 11 from 1)
> ==16330== malloc/free: in use at exit: 212,990 bytes in 10,088 blocks.
> ==16330== malloc/free: 14,902 allocs, 4,814 frees, 2,269,270 bytes allocated.
> ==16330== For counts of detected errors, rerun with: -v
> ==16330== searching for pointers to 10,088 not-freed blocks.
> ==16330== checked 76,480 bytes.
> ==16330==
> ==16330== LEAK SUMMARY:
> ==16330==    definitely lost: 212,160 bytes in 10,016 blocks.
> ==16330==      possibly lost: 8 bytes in 1 blocks.
> ==16330==    still reachable: 822 bytes in 71 blocks.
> ==16330==         suppressed: 0 bytes in 0 blocks.
> ==16330== Use --leak-check=full to see details of leaked memory.

> Does anybody investigated this any further ?



-- 
Alen