This is the mail archive of the
libc-help@sourceware.org
mailing list for the glibc project.
Re: Unexplainable deadlock detection assert in libpthread
- From: Szabolcs Nagy <szabolcs dot nagy at arm dot com>
- To: Patrick Schlangen <patrick at schlangen dot me>, "Schmitz, Arne" <Arne dot Schmitz at nuance dot com>
- Cc: nd at arm dot com, libc-help at sourceware dot org
- Date: Fri, 24 Nov 2017 12:05:44 +0000
- Subject: Re: Unexplainable deadlock detection assert in libpthread
- Authentication-results: sourceware.org; auth=none
- Authentication-results: spf=none (sender IP is ) smtp.mailfrom=Szabolcs dot Nagy at arm dot com;
- Nodisclaimer: True
- References: <MWHPR0501MB3916FF6043F5BD980262093FE3260@MWHPR0501MB3916.namprd05.prod.outlook.com> <a5abda49c06b39b44cfeacf53ca1c353@mail.b1g.net>
- Spamdiagnosticmetadata: NSPM
- Spamdiagnosticoutput: 1:99
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
>
>