Re: [libmicrohttpd] Memory leak and global variables

[LRN]

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