Hi Verdi I use valgrind quite extensively and, in my experience, valgrind does not lie ... If you do not believe valgrind, try some other memory debugger such as dmalloc or Intel's pin. Or write a small shared library overloading malloc/calloc/free and keeping a log of each memory request and preload it into your application via LD_PRELOAD. Regards, Vadym Krevs Verdi March wrote:
Aschwin Marsman wrote:
What is the exact message you get?
How do you call valgrind?
The program is a simulator, called rsim. I call valgrind with the following: valgrind --leak-check=yes ./rsim -i haha.ev The -i haha.ev is arguments for rsim.
And here're the output: ------------------------------------------------------------------------- ==18483== ==18483== ERROR SUMMARY: 4 errors from 2 contexts (suppressed: 20 from 3) ==18483== malloc/free: in use at exit: 73828228 bytes in 4129 blocks. ==18483== malloc/free: 4724 allocs, 595 frees, 73902008 bytes allocated. ==18483== For counts of detected errors, rerun with: -v ==18483== searching for pointers to 4129 not-freed blocks. ==18483== checked 82564948 bytes. ==18483== ==18483== ==18483== 48 bytes in 2 blocks are definitely lost in loss record 5 of 14 ==18483== at 0x1B901B95: calloc (in /usr/lib/valgrind/vgpreload_memcheck.so) ==18483== by 0x8053D02: newRequest (request.c:51) ==18483== by 0x8056096: stabilize (stabilize.c:46) ==18483== by 0x8056797: main (sim.c:126) ==18483== ==18483== LEAK SUMMARY: ==18483== definitely lost: 48 bytes in 2 blocks. ==18483== possibly lost: 0 bytes in 0 blocks. ==18483== still reachable: 73828180 bytes in 4127 blocks. ==18483== suppressed: 0 bytes in 0 blocks. ==18483== Reachable blocks (those to which a pointer was found) are not shown. ==18483== To see them, rerun with: --show-reachable=yes -------------------------------------------------------------------------
Is it possible to post/email a small compilable example which shows your problem?
Unfortunately that'll be quite a difficult thing to do :( I'll give a summary instead, hope it can be useful:
The newRequest() functions is used almost everywhere, but only in stabilize() that valgrind detected a memleak.
What stabilize() does is: Request r = newRequest(...); printf("STAB_NEW\n");
//Only this function creates request with this req_type r->type = REQ_TYPE_STABILIZE;
if (TRUE) { //continue processing this request //processRequest(); } else { //cancel request free(r); printf("STAB_FREE\n"); }
A request is processed in another function, processRequest(). processRequst() should occur sometime in the future, so instead of stabilize() invoke processRequest(), there is "scheduler" that invokes processRequest(). Note that the simulator is sequential, not multi-threaded.
What processRequest() does is to simulate the request until the request is finished. So, there will be several free(r) in processRequest(). Before every free(r) in processRequest(), I print a message. At the end, it'll look like this: if (must_free_request) { if (r->type == REQ_TYPE_STABILIZE) printf("STAB_FREE\n");
free(r); }
As you can see, there's nothing fancy in the code.
Regards, Verdi
********************************************************************** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message.