----- Original Message ----- > From: "Stefan Seefeld" <[email protected]> > To: "Mathieu Desnoyers" <[email protected]> > Cc: [email protected] > Sent: Sunday, February 9, 2014 11:28:38 AM > Subject: Re: [lttng-dev] RFC: Fix crash in dlerror() > > On 02/08/2014 05:22 PM, Mathieu Desnoyers wrote: > > > Interesting approach. > > I assume here you are referring to the temporary static allocator we use > during calloc initialization, not my initializing realloc at the same time ?
Actually, I'm referring to your idea of initializing more than just the function we need whenever the allocator is first used. > > > Then I wonder if we couldn't simply lookup every symbol > > we're interested in whenever any of the overridden function is called and > > we notice a NULL pointer, and provide a simplistic "static" allocator for > > every function overridden. > > While I agree that a consistent technique to solve the initialization > problem has a lot of appeal, I'm actually hesitant in this particular > case: One important limitation of the static allocator is that it > requires an upper bound for the buffer. This works fine if we know the > circumstance where it is used (I believe dlsym() itself calls calloc() > to allocate a global structure that requires 32 bytes). > > The case I discovered on Friday, however, uses realloc() from within > vasprintf(), which needs to grow a buffer to hold an error message, and > I don't think the size of that is bounded. Therefore, using a static > allocator in that situation seems dangerous. By inspecting the source, this error message is made of: - objname (object/file name), - errstring (error detail) I understand your concern about unbounded size for those strings. Since the statically allocated array is 4kB, one thing we could do is rely on a call to mmap() to handle allocations that require more space than available. > An entirely different argument is that you are suggesting to rewrite an > entire library (albeit a small one), when we are trying to get a bugfix > into a release even after code freeze. But who am I to tell you that. ;-) The last thing I want is to start playing hide-and-seek with bugs resulting from interactions between the lttng-ust malloc wrapper and libc. From my point of view, anything we can do to minimize the risk of interaction issues is a huge gain in maintainability, so I'd be OK with fixing things up all throughout this library, rather than going case-by-case for each bug encountered. Thoughts ? Thanks, Mathieu > > Regards, > Stefan > > -- > Stefan Seefeld > CodeSourcery / Mentor Graphics > http://www.mentor.com/embedded-software/ > -- Mathieu Desnoyers EfficiOS Inc. http://www.efficios.com _______________________________________________ lttng-dev mailing list [email protected] http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
