valgrind has discovered a small (26 bytes) memory leak in marx2fits:
==11332== Memcheck, a memory error detector
==11332== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al.
==11332== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info
==11332== Command: /melkor/d1/guenther/marx/dev/bin/marx2fits /tmp/marxout/marx9 /tmp/marxout/marx9/events.fits
==11332== Parent PID: 11253
==11332==
==11332==
==11332== HEAP SUMMARY:
==11332== in use at exit: 45,543 bytes in 759 blocks
==11332== total heap usage: 2,814 allocs, 2,055 frees, 297,511 bytes allocated
==11332==
==11332== 26 bytes in 1 blocks are definitely lost in loss record 25 of 47
==11332== at 0x4A06A2E: malloc (vg_replace_malloc.c:270)
==11332== by 0x41DA67: malloc_internal (pfmisc.c:60)
==11332== by 0x41DC64: _pf_create_string (pfmisc.c:87)
==11332== by 0x41E7BC: pf_get_parameters (pftable.c:86)
==11332== by 0x401E03: get_simulation_info (marx2fits.c:2365)
==11332== by 0x403AD8: main (marx2fits.c:3264)
==11332==
==11332== LEAK SUMMARY:
==11332== definitely lost: 26 bytes in 1 blocks
==11332== indirectly lost: 0 bytes in 0 blocks
==11332== possibly lost: 0 bytes in 0 blocks
==11332== still reachable: 45,517 bytes in 758 blocks
==11332== suppressed: 0 bytes in 0 blocks
==11332== Reachable blocks (those to which a pointer was found) are not shown.
==11332== To see them, rerun with: --leak-check=full --show-reachable=yes
==11332==
==11332== For counts of detected and suppressed errors, rerun with: -v
==11332== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 6 from 6)
I've traced the lines and I don't understand were that comes from; I probably need to revisit it when I know more about C pointers and can read wrap my head around the syntax faster.
In any case, this is related to the values in the parameter file, that means that the leak will be constant even for very large MARX files. Thus, fixing this is not a priority.
valgrind has discovered a small (26 bytes) memory leak in marx2fits:
I've traced the lines and I don't understand were that comes from; I probably need to revisit it when I know more about C pointers and can read wrap my head around the syntax faster. In any case, this is related to the values in the parameter file, that means that the leak will be constant even for very large MARX files. Thus, fixing this is not a priority.