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: Mon, 3 Nov 2008 16:06:48 -0400
- 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=t5Yp++FEjgGa8zol5eX+rzKmK06Uw1ZNPObnjltx7y4=; b=EoRtm3e0pT0ImVZxPVjnAl2erIQ89FWCsgsgO+TXBmgwhBpox8R0DEiThSFanFaCPG AeKEDXfpeHwuaagtuwBgrPs/yg+2uPS3ysclAoTfgyrGp/sETvYYFhj4FKc6iqkVOLxo gdBwNmtyuZh+DKRFaHtQ03Ei4Ec6XcB8pWeqc=
- 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=a20Kf4jqJE/+D9k5R3wtQEdvcVWRxpVOggs8CVu5fBST0Dyn+/swVDjxwASIvVc4Qr rc7USHtTKlYWonAU2+WMXLMAArd1ftSD63pPqtGN2QNR8ARW/0owhkPkJeehOeGkFswj oVLjBKohqkp05M+xni16TShS/D/VWxoqpedu4=
- References: <C7E4B93E1693CA4AA0533C881F5B751E10AC689828@exchangehp1.softservecom.com> <C7E4B93E1693CA4AA0533C881F5B751E10AC68982A@exchangehp1.softservecom.com>
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.
Cheers,
Carlos.