This is the mail archive of the
mailing list for the glibc project.
RE: [EXTERNAL] Re: Unexplainable deadlock detection assert in libpthread
Indeed we use PTHREAD_MUTEX_ERRORCHECK_NP.
And no, we have nothing in the signal handler.
> -----Original Message-----
> From: Szabolcs Nagy [mailto:firstname.lastname@example.org]
> Sent: Freitag, 24. November 2017 13:06
> To: Patrick Schlangen <email@example.com>; Schmitz, Arne
> Cc: firstname.lastname@example.org; email@example.com
> Subject: [EXTERNAL] Re: Unexplainable deadlock detection assert in
> 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
> > 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
> _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