RE: Glibc 2.5 - dlsym issue in threaded app.

[Vitaliy Ivanov <vivanov at softservecom dot com>]

Carlos,

> -----Original Message-----
> From: patofiero@gmail.com [mailto:patofiero@gmail.com] On Behalf Of
> Carlos O'Donell
> Sent: Monday, November 03, 2008 10:07 PM
> To: Vitaliy Ivanov
> Cc: libc-help@sourceware.org
> Subject: Re: Glibc 2.5 - dlsym issue in threaded app.
>
> On Fri, Oct 31, 2008 at 11:45 AM, Vitaliy Ivanov
> <vivanov@softservecom.com> wrote:
> > So, what I understand is that dlsym when linked with pthreads is
> calling changed calloc and we enter infinite loop.
> > When we are not linking with pthreads is seems like dlsym doesn't
> call calloc at all.
> >
> > Are you aware of this? What is the practice to avoid this endless
> loop?
>
> You will always have this problem whenever you have a possibly
> circular reference e.g. calloc which depends on calloc.
>
> You must break the dependency by providing your own static buffer, and
> returning calloc references to that static buffer, for all of the
> calloc calls that can possibly be made by the dynamic loader calls
> during the resolution of the next calloc symbol. Once you run out of
> static calloc space, you can fall back to calling the next calloc
> symbol, hopefully by this point all the internal library calloc's will
> be handled.
>
> I can see only one calloc reference in libc/dlfcn/dlerror.c
> (_dlerror_run), and it allocates ~20 bytes of data. Once that data is
> allocated, it won't be allocated again.

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 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.

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

V.