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

[Stefan Seefeld]

Hi Jérémie,

thanks for the quick review. I agree with the fragility of the calloc()
hack. However, we aren't the only ones hitting this circular dependency
(as google confirms).
Some more investigation reveals that dlsym() is in fact prepared for
calloc() to return NULL (in which case an internal static buffer is
used. And yes, it appears to check for that case during cleanup.)

Thus I have updated the patch, addressing all of the issues you raise,
and replaced the "dummy_malloc" business by a simple dummy_calloc()
returning NULL. This appears to be working fine.

Meanwhile, I'd like to understand your suggestion, so let me follow up
on that, too:

On 07/29/2013 07:19 PM, Jérémie Galarneau wrote:

> I may be missing something, but since this structure is allocated only
> once per thread, subsequent calls from the same thread to dlsym()
> should not result in another call to calloc(). That should make it
> possible to call malloc() in dummy_calloc() without causing the
> recursion.

You are right. But the problem is that, if I call malloc() in
dummy_calloc(), I indirectly end up calling dlsym() from within dlsym()...

> Perhaps we could also forego this mechanism completely and initialize
> the symbols from a constructor since this library is meant to be
> LD_PRELOAD-ed?

I don't quite understand what you are suggesting. dlsym() still calls
calloc(), so our wrapper still needs to check whether initialization has
already been completed, and if not, use a fallback.

The code may be reorganized, but that doesn't seem to make it any simpler.

Regards,
	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: 3133 bytes
Desc: not available
URL: <http://lists.lttng.org/pipermail/lttng-dev/attachments/20130730/4f4a49a3/attachment.bin>