This is the mail archive of the
libc-help@sourceware.org
mailing list for the glibc project.
RE: [EXTERNAL] Re: Unexplainable deadlock detection assert in libpthread
Hi,
Indeed we use PTHREAD_MUTEX_ERRORCHECK_NP.
And no, we have nothing in the signal handler.
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
> >
> >