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: pthread_mutex_lock hang during tls_get_addr_tail()


On Sat, 2016-09-10 at 15:43 -0700, Paul Pluzhnikov wrote:
> On Sat, Sep 10, 2016 at 1:33 PM, Paul Smith <paul@mad-scientist.net> wrote:
> 
> > As far as I'm aware, no signals are being caught in the thread where
> > this hang occurs.
> 
> Well, I guess it's something different then.
> 
> I took a look at tls_get_addr_tail, and the only lock it takes is the
> loader lock. It also locks it with __rtld_lock_lock_recursive, which
> means the thread can't self-deadlock.
> 
> The key question then is: what other thread is holding the loader
> locked, and what prevents that other thread from completing whatever
> loader operation it's in?

All the other threads are hanging out in pthread_cond_wait, from what I
can remember, except maybe a few waiting on recv().  However I haven't
examined them closely (because many of them were started by the JVM I
don't have really useful stacktraces for many threads).  What sorts of
things should I be looking for?  Does anything else take this lock,
other than a dlopen() or similar?  Certainly my library doesn't do any
dlopen() or similar.

I'll try to get the user to send me a complete stack trace for all
threads, but it may not happen until Monday.


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