This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Should glibc be fully reentrant? What do we allow interposed symbols to do?


On 10/28/2014 08:24 AM, Will Newton wrote:
>> If you can write a test case I will look at it.
> 
> I had mis-remembered the details of the issue. What I did find was
> that using LD_PRELOAD to override malloc and calling dlsym can be a
> problem. This was caused by the following code in dlfcn/dlerror.c:

Thanks for looking!
 
>       /* We don't use the static buffer and so we have a key.  Use it
>          to get the thread-specific buffer.  */
>       result = __libc_getspecific (key);
>       if (result == NULL)
>         {
>           result = (struct dl_action_result *) calloc (1, sizeof (*result));
>           if (result == NULL)
>             /* We are out of memory.  Since this is no really critical
>                situation we carry on by using the global variable.
>                This might lead to conflicts between the threads but
>                they soon all will have memory problems.  */
>             result = &last_result;
>           else
>             /* Set the tsd.  */
>             __libc_setspecific (key, result);
> 
> The calloc call can cause a loop and overflow the stack. If you use a
> malloc hook and enable/disable the hook correctly then everything is
> OK I think.

Right, this is a developer problem.

Infinite loops are your own fault. You need to detect them and terminate
the recursion with memory from a static buffer or the original malloc.
There isn't any other solution I can suggest.

Does that make sense?

Cheers,
Carlos.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]