This is the mail archive of the libc-help@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]