|
From: Colin M. <col...@pi...> - 2009-07-13 10:56:20
|
simone marras wrote: > Hi Colin, > > Thanks for replying. Here I send you the main.c written for the test > (no "apparent allocation"), and the valgrind output. > I hope this helps you > > thank you in advance, > Simone > > -------------------------------------------------------------------------------------------- > Valgrind output: > > > ==18862== > ==18862== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0) > ==18862== malloc/free: in use at exit: 4,436 bytes in 9 blocks. > ==18862== malloc/free: 9 allocs, 0 frees, 4,436 bytes allocated. > ==18862== For counts of detected errors, rerun with: -v > ==18862== searching for pointers to 9 not-freed blocks. > ==18862== checked 1,124,356 bytes. > ==18862== > ==18862== LEAK SUMMARY: > ==18862== definitely lost: 0 bytes in 0 blocks. > ==18862== indirectly lost: 0 bytes in 0 blocks. > ==18862== possibly lost: 0 bytes in 0 blocks. > ==18862== still reachable: 0 bytes in 0 blocks. > ==18862== suppressed: 4,436 bytes in 9 blocks. > > > Simone, The "suppressed: 4,436 bytes in 9 blocks." line indicates that Valgrind has detected an error but has been told not to report the details. This behaviour is controlled by a suppression file. Since you did not specify a suppressions file, I'd assume it in the default suppression file. (Use valgrind -v to find its name). Therefore, I'd further assume that it is a known bug in a runtime library you are using (possible the stdio) According to the manual, Valgrind tries to force glibc (the C runtime library) to free all its memory by calling __libc_freeres(), I'm not sure why a suppression was used. I can't see a way to tell Valgrind not to use its default suppression file, which would ascertain this for certain. HTH, Colin S. Miller |