This is the mail archive of the
libc-help@sourceware.org
mailing list for the glibc project.
RE: Glibc 2.5 - dlsym issue in threaded app.
- From: Vitaliy Ivanov <vivanov at softservecom dot com>
- To: Carlos O'Donell <carlos at systemhalted dot org>
- Cc: "libc-help at sourceware dot org" <libc-help at sourceware dot org>, Vitaliy Ivanov<vivanov at softservecom dot com>
- Date: Wed, 5 Nov 2008 13:57:50 +0200
- Subject: RE: Glibc 2.5 - dlsym issue in threaded app.
- Accept-language: en-US
- Acceptlanguage: en-US
- References: <C7E4B93E1693CA4AA0533C881F5B751E10AC689828@exchangehp1.softservecom.com> <C7E4B93E1693CA4AA0533C881F5B751E10AC68982A@exchangehp1.softservecom.com><119aab440811031206y49f785d1j62f6b278ec89721e@mail.gmail.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.