[lttng-dev] [PATCH lttng-ust] Add trace support for calloc and realloc.

[Stefan Seefeld]

On 08/02/2013 09:18 PM, Mathieu Desnoyers wrote:
> Please have a look at my implementation of quick and dirty malloc/free
> tracker here:
>
> https://github.com/efficios/memleak-finder
>
> file: memleak-finder.c
>
> Implementing a work-around for calloc vs dlsym was indeed tricky. The
> solution I got there works fine so far (static array used for this
> special-case). I think we might get the free() case to be more solid by
> checking if the address being freed is in the static buffer range.

I played a little with this code (e.g. by removing the "constructor"
attribute from the do_init() function, to increase the chances that I
could see static_calloc() being used in my own code).
I found one bug (where the static buffer size adjustment was wrong, so
the second time static_calloc was called a pointer pointing into the
previous buffer would be returned).
And I did observe a crash without the appropriate adjustment to free().

> If you could submit a patch that improves memleak-finder.c to get this
> right, it would be very much appreciated.

Please find attached a small patch for this. As you can see, if the
pointer falls into the range of the static buffer, free() does nothing.
("freeing" the buffer properly would require much more work,
and arguably falls outside the scope of what is needed here, since
static_calloc() is really only required during startup, and thus should
never run out of space.


> Then, I recommend porting the code from memleak-finder.c to UST
> liblttng-ust-libc-wrapper. The approach I used in memleak-finder.c seems
> to work quite well, and is clearly more complete that what we find in
> liblttng-ust-libc-wrapper currently.

Yes, with the adjusted free() implementation as per this patch, I think
this is a robust solution. Do you think we need any form of multi-thread
protection ? Or can we assume that library initialization will have
completed by the time multiple threads could possibly call calloc() ?

    Stefan

-- 
Stefan Seefeld
CodeSourcery / Mentor Graphics
http://www.mentor.com/embedded-software/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: patch
Type: text/x-patch
Size: 1179 bytes
Desc: not available
URL: <http://lists.lttng.org/pipermail/lttng-dev/attachments/20130805/7335ad4b/attachment.bin>