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: "Carlos O'Donell" <carlos at systemhalted dot org>
- To: "Vitaliy Ivanov" <vivanov at softservecom dot com>
- Cc: "libc-help at sourceware dot org" <libc-help at sourceware dot org>
- Date: Wed, 5 Nov 2008 07:47:55 -0500
- Subject: Re: Glibc 2.5 - dlsym issue in threaded app.
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=jL4nBTBY3vOgoqi6pF4z9xl/LBYlL0AKKgSodIgnIXQ=; b=PF3US1u7Oc8duvqsUSxgXFMpIK6pQeZ3Exeh4ACKLXcJ5toiEg8dpQM+9+fdx7B9fc Mlfpu7cLdMQcMD1qNwLjZxlEFjKTa8cEiXB60NvALbijtJSHz1VE9XoksFI3F1NsnnVE n7NO6MfnFttHYx159P1Rub53s5pB/HHCDU7yI=
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=ook+t2i7dFue7RWC2aDjnJmmairBeBcAfhY/KEgny0/KmCoapN/G05wAF/oX5kX4iJ zvqfcFJaDUALhGNaYjqaLNk7ymqaq1nr/Mz2fN9JdWJmBTbBchkczx7UmmnaEGLmV8nf 08Xa6H2dQDo8+1i/xvImMjCHR7GKB3/CCMKgo=
- References: <C7E4B93E1693CA4AA0533C881F5B751E10AC689828@exchangehp1.softservecom.com> <C7E4B93E1693CA4AA0533C881F5B751E10AC68982A@exchangehp1.softservecom.com> <119aab440811031206y49f785d1j62f6b278ec89721e@mail.gmail.com> <C7E4B93E1693CA4AA0533C881F5B751E10AC68999A@exchangehp1.softservecom.com>
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.