On 29.08.2014 22:59, Nicolas Mora wrote: > Hello again, > > Le 2014-08-28 15:51, Kenneth Mastro a écrit : >> Have you tried Valgrind or some printfs to make sure that free is called >> for every malloc you're doing? Even a simple counter would help. I'm >> guessing you really need to make absolutely sure the free is getting >> called for every one - especially with lots of early-returns. >> > I traced my program with printf every time I malloc and free variables. > I have made a few tests, and as far I can tell, all mallocs variables > are freed every time. > > Unfortunately, Raspbian uses a hack that won't be supported by valgrind, > so valgrind detects an early error. Here is valgrind output on the rpi > (my program is compiled with the debug options). > > In the next days, I will monitor the program on another platform with > valgrind. By taking a closer look, I found one leak, but it's not over yet.
FWIW, you can go a long way by hacking your program to use your own implementations of functions like malloc() and free(). In these implementations you can record the backtrace and add it, together with the allocated/freed pointer, to an in-memory structure (usually an array that you re-size when it becomes too small). Obviously, protected by a lock or a mutex. On frees you can remove items from that structure (since you are debugging memory leaks, not use-after-frees; for use-after-frees you have to retain pointers after they are freed in order to later trace the free() call). If you can ensure that all code uses these implementations (i.e. you never call free() on a pointer allocated by some other library), you can soup up the performance by allocating more bytes than requested, putting service info at the start of memory chunk, and returning a pointer to the rest of it. When it's freed, you do the opposite - look back by N bytes from the pointer you've been given. It's a good idea to make first service info item a pointer to the rest of the chunk that is returned, this way you can later compare that you've got the right stuff. Anyway, in this case the global array of allocations can be used differently (you don't need to search through it every time you free(), service info would have the index at hand), which is why this is faster. You can then dump the structure into stdout or a file at your convenience (on exit, on crash, on signal - anything you want). This is how i debugged memory leaks in GNUnet on Windows, where valgrind isn't available. Also, check out libc documentation, it might have some debug helpers for dumping the heap contents. -- O< ascii ribbon - stop html email! - www.asciiribbon.org
0x922360B0.asc
Description: application/pgp-keys
signature.asc
Description: OpenPGP digital signature
