RE: [EXTERNAL] Re: Unexplainable deadlock detection assert in libpthread

["Schmitz, Arne" <Arne dot Schmitz at nuance dot com>]

Hi,

by now we isolated the crash to a minimal test program. It seems that the necessary conditions are two threads and one mutex that try to acquire a lock both. 

Using Linux 3.14.79-102 we CANNOT reproduce the issue, but with Linux 3.18.40 we can reproduce it, using the same binary. So maybe it is a bug in the kernel that has been fixed in the meantime? How is the deadlock handling distributed between libc and the kernel?

Test program is attached, if anyone wants to give it a try.

Other than that we think the solution is to upgrade to a more recent kernel.

Best regards,

Arne


> -----Original Message-----
> From: Szabolcs Nagy [mailto:szabolcs.nagy@arm.com]
> Sent: Freitag, 24. November 2017 13:06
> To: Patrick Schlangen <patrick@schlangen.me>; Schmitz, Arne
> <Arne.Schmitz@nuance.com>
> Cc: nd@arm.com; libc-help@sourceware.org
> Subject: [EXTERNAL] Re: Unexplainable deadlock detection assert in
> libpthread
> 
> On 24/11/17 12:01, Patrick Schlangen wrote:
> > Hi Arne,
> >
> > can you give some more information on the involved mutex, i.e. is it a
> > recursive a PTHREAD_MUTEX_ERRORCHECK_NP or a
> PTHREAD_MUTEX_FAST_NP
> > mutex (the latter would be the default AFAIR)?
> >
> > If it's of 'default' PTHREAD_MUTEX_FAST_NP type, to my understanding
> > of the code, it would lead to the observed assertion and the check
> > returning EDEADLK you pointed out in your marker would NOT be
> performed.
> >
> 
> _FAST_NP mutex does not check for EDEADLK errors only error checking and
> recursive mutexes do.
> 
> > You don't, by any chance, lock the mutex from any signal handler?
> >
> > Best Regards,
> >
> > Patrick
> >
> >

Attachment: pthread_crash.c
Description: pthread_crash.c