This is the mail archive of the
libc-help@sourceware.org
mailing list for the glibc project.
Re: deadlock in __lll_lock_wait() @ /lib64/libpthread.so.0
- From: "Carlos O'Donell" <carlos at systemhalted dot org>
- To: Paweł Sikora <pluto at agmk dot net>
- Cc: libc-help at sourceware dot org
- Date: Thu, 15 Nov 2012 17:03:14 -0500
- Subject: Re: deadlock in __lll_lock_wait() @ /lib64/libpthread.so.0
- References: <4538295.xuXUE72LFT@localhost>
On Thu, Nov 15, 2012 at 12:58 PM, PaweÅ Sikora <pluto@agmk.net> wrote:
> Hi,
>
> i'm playing with some EDA simulator which loads dynamically (via dlopen) my plugin.
> during plugin initialization (global ctors) it deadlocks on the __lll_lock_wait.
> i'm observing this issue on RHEL-5/CentOS-5 with glibc-2.5-58.el5_6.4.
> is it a known bug on the 2.5 branch?
That was released 7 years ago. I don't remember anything from that
time period :-)
> btw, i can workaround this issue with -Wl,-z,now linking flag to avoid lazy
> symbol binding but i'd like to avoid this way if possible.
Why do you assume it's a glibc bug?
It will always deadlock in ___lll_lock_wait for any deadlock since that's the
lowest level function for the locking implementation.
At this point it is either an application bug or a glibc bug, but I see nothing
in the gdb stack traces that points either way.
You'll need to debug more to find out.
Cheers,
Carlos.