Tim,
I get the errors now (I forgot the --leak-check=yes option).
> > > At the moment though, I cannot make valgrind give me these errors (that
> > > is, running your program under valgrind --tool=memcheck gives me zero
> > > errors). Which valgrind tool did you use?
> > >
> >
> > SURF showed a much bigger "leak" of 64kB after reading one fits header.
The question is, does the leak continue to grow indefinitately in size as
you read more headers and do more AST stuff, or does it reach a fixed size
at which it remains no matter how much AST stuff you do? Presumably a
fixed size memory leak of the order of KB is no real problem? Both of the
locations indicated by valgrind using your test program are legitimate
one-off memory allocations. If, on the other hand, the memory leak
continues to grow indefinately as more objects are created and more
processing occurs, then there are bugs which need fixing.
Let me know if you come across any other memory leaks. In the mean time,
I'll try running some of my AST test progs under valgrind to check for
leaks again.
David
> > I'm using valgrind-20031012 (memcheck). I'll try again with a more
> > "modern" valgrind...
> >
>
> and with valgrind v2.2-0 I get (current CVS AST):
>
> /sw/bin/valgrind --leak-check=yes --tool=memcheck ./a.out
> ==18425== Memcheck, a memory error detector for x86-linux.
> ==18425== Copyright (C) 2002-2004, and GNU GPL'd, by Julian Seward et al.
> ==18425== Using valgrind-2.2.0, a program supervision framework for x86-linux.
> ==18425== Copyright (C) 2000-2004, and GNU GPL'd, by Julian Seward et al.
> ==18425== For more details, rerun with: -v
> ==18425==
> ==18425==
> ==18425== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 31 from 1)
> ==18425== malloc/free: in use at exit: 116 bytes in 7 blocks.
> ==18425== malloc/free: 15 allocs, 8 frees, 1342 bytes allocated.
> ==18425== For counts of detected errors, rerun with: -v
> ==18425== searching for pointers to 7 not-freed blocks.
> ==18425== checked 3432776 bytes.
> ==18425==
> ==18425== 52 bytes in 3 blocks are possibly lost in loss record 1 of 2
> ==18425== at 0x1B904E5C: malloc (vg_replace_malloc.c:131)
> ==18425== by 0x1B9F2866: astMalloc_ (memory.c:707)
> ==18425== by 0x1B9F2756: astGrow_ (memory.c:489)
> ==18425== by 0x1B9F3F34: astSetCopy_ (object.c:1781)
> ==18425==
> ==18425==
> ==18425== 64 bytes in 4 blocks are possibly lost in loss record 2 of 2
> ==18425== at 0x1B9058DA: realloc (vg_replace_malloc.c:197)
> ==18425== by 0x1B9F294D: astRealloc_ (memory.c:833)
> ==18425== by 0x1B9F278C: astGrow_ (memory.c:506)
> ==18425== by 0x1B9F5378: astBegin_ (object.c:3686)
> ==18425==
> ==18425== LEAK SUMMARY:
> ==18425== definitely lost: 0 bytes in 0 blocks.
> ==18425== possibly lost: 116 bytes in 7 blocks.
> ==18425== still reachable: 0 bytes in 0 blocks.
> ==18425== suppressed: 0 bytes in 0 blocks.
> ==18425== Reachable blocks (those to which a pointer was found) are not shown.
> ==18425== To see them, rerun with: --show-reachable=yes
>
>
> PS
> mapping.c: In function `Rate':
> mapping.c:7080: warning: `fitok' might be used uninitialized in this
> function
>
> --
> Tim Jenness
> JAC software
> http://www.jach.hawaii.edu/~timj
>
|