This is the mail archive of the libc-help@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: Glibc 2.5 - dlsym issue in threaded app.


On 11/5/08, Vitaliy Ivanov <vivanov@softservecom.com> wrote:
> Thanks, I did it something like this:
>
> //-----------------------------------------------------------------------------
>
> void * calloc(size_t num, size_t sz)
> {
>         static bool memUsed; // Counting on default initialization to 0
>
> #if defined(__GLIBC__) && __GLIBC__ == 2
> # if defined (__GLIBC_MINOR__) && __GLIBC_MINOR__ >= 5
>         if (!memUsed && num == 1 && sz == 20)
>         {
>                 memUsed = true;
>                 memset(extra_mem, 0, 20);
>                 return (void *) extra_mem;
>         };
> # else
>         if (!memUsed && num == 1 && sz == 16)
>         {
>                 memUsed = true;
>                 memset(extra_mem, 0, 16);
>                 return (void *) extra_mem;
>         };
> # endif
> #endif

The GLIBC version checks are completely unnecessary. Create a static
buffer of N bytes, and return references to this buffer on a first
come first serve basis, clearly the first calloc call is going to be
in the resolution of the next calloc call.

> ....
> //-----------------------------------------------------------------------------
>
> The problem is that structure
>
> struct dl_action_result
>   {
>     int errcode;
>     int returned;
>     bool malloced;
>     const char *objname;
>     const char *errstring;
>   };
>
> ... was changed from 2.3.2 glibc to 2.5 and new bool param was added.

This has no bearing on the problem at hand.

> What I don't understand is that why it's reproduced with pthread linked in?

When threads are linked into your application it triggers the use of
thread specific error results (instead of a static global buffer). For
any thread (including thread 0 which is running main(...)) which calls
dlsym a struct dl_action_result will be allocated once via calloc. The
memory will be freed (see free_key_mem) later by the destructor
specified for the pthread key data.

Cheers,
Carlos.


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