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
On Thursday 15 of November 2012 17:03:14 Carlos O'Donell wrote:
> 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 :-)
RHEL5 has at least 10 years of commercial support and many companies still use it ;-)
> > 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.
it works fine with newer glibc-2.12 from RHEL6 and with glibc-2.16 from other linux distro.
moreover, these traces from different threads stuck in the same point -> _L_lock_1127,
so i assume that it is probably a glibc-2.5 bug fixed in newer version. the main problem
is to locate the right fix in glibc.git mirror and check RHEL5 updates against it.
i can't force customer to update theirs RHEL5 cluster without strong arguments :)
BR,
PaweÅ.
Thread 3 (Thread 0x44f72940 (LWP 29969)):
#0 0x0000003e6880d4c4 in __lll_lock_wait () from /lib64/libpthread.so.0
#1 0x0000003e68808e35 in _L_lock_1127 () from /lib64/libpthread.so.0
#2 0x0000003e68808d33 in pthread_mutex_lock () from /lib64/libpthread.so.0
#3 0x0000003e67809dcb in _dl_lookup_symbol_x () from /lib64/ld-linux-x86-64.so.2
#4 0x0000003e6780cf05 in _dl_fixup () from /lib64/ld-linux-x86-64.so.2
#5 0x0000003e67812982 in _dl_runtime_resolve () from /lib64/ld-linux-x86-64.so.2
(...)
#9 0x0000003e6880673d in start_thread () from /lib64/libpthread.so.0
#10 0x0000003e67cd44bd in clone () from /lib64/libc.so.6
#11 0x0000000000000000 in ?? ()
Thread 1 (Thread 0x2b294f828c90 (LWP 29947)):
#0 0x0000003e6880d4c4 in __lll_lock_wait () from /lib64/libpthread.so.0
#1 0x0000003e68808e35 in _L_lock_1127 () from /lib64/libpthread.so.0
#2 0x0000003e68808d33 in pthread_mutex_lock () from /lib64/libpthread.so.0
#3 0x0000003e67d08f71 in _dl_addr () from /lib64/libc.so.6
#4 0x00002b294bbc9603 in backtracexx::lookupSymbol(backtracexx::Frame&) ...
#5 0x00002b294bbc9e9b in backtracexx::(anonymous namespace)::helper(_Unwind_Context*, ...
#6 0x0000003e6c808914 in _Unwind_Backtrace () from /lib64/libgcc_s.so.1
#7 0x00002b294bbc95a9 in backtracexx::scan(void*) () from ...
#8 0x00002aaaafa95d95 in eh::signalFilter () from ...
#9 <signal handler called>
#10 0x0000003e6880aee9 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
#11 0x00002b294ad8149e in QWaitCondition::wait(QMutex*, unsigned long) () from ...
#12 0x00002b294ad80600 in QThread::wait(unsigned long) () from ...
#13 0x0000000000492a11 in ?? ()
#14 0x0000003e67c1d994 in __libc_start_main () from /lib64/libc.so.6