This is the mail archive of the
mailing list for the libstdc++ project.
Re: [patch] Enable lightweight checks with _GLIBCXX_ASSERTIONS.
- From: Florian Weimer <fweimer at redhat dot com>
- To: Jonathan Wakely <jwakely at redhat dot com>
- Cc: Martin Sebor <msebor at gmail dot com>, libstdc++ at gcc dot gnu dot org, gcc-patches at gcc dot gnu dot org, FranÃois Dumont <frs dot dumont at gmail dot com>
- Date: Sat, 26 Sep 2015 22:49:56 +0200
- Subject: Re: [patch] Enable lightweight checks with _GLIBCXX_ASSERTIONS.
- Authentication-results: sourceware.org; auth=none
- References: <20150907182755 dot GP2631 at redhat dot com> <87r3mauiud dot fsf at mid dot deneb dot enyo dot de> <20150907195939 dot GT2631 at redhat dot com> <55EEF828 dot 4060707 at redhat dot com> <20150908154535 dot GX2631 at redhat dot com> <55F05728 dot 1000209 at redhat dot com> <55F1B041 dot 5060507 at gmail dot com> <55F1B1F5 dot 4060300 at redhat dot com> <55F1B682 dot 1040109 at gmail dot com> <55F69A17 dot 1000504 at redhat dot com> <20150926195209 dot GL12094 at redhat dot com>
On 09/26/2015 09:52 PM, Jonathan Wakely wrote:
> Would changes like this be suitable for _FORTIFY_SOURCE?
> diff --git a/libstdc++-v3/include/std/mutex b/libstdc++-v3/include/std/mutex
> index 5e5ced1..074bf26 100644
> --- a/libstdc++-v3/include/std/mutex
> +++ b/libstdc++-v3/include/std/mutex
> @@ -70,7 +70,12 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
> __recursive_mutex_base& operator=(const __recursive_mutex_base&) = delete;
> #ifdef __GTHREAD_RECURSIVE_MUTEX_INIT
> +# if _GLIBCXX_ASSERTIONS && defined(PTHREAD_ERRORCHECK_MUTEX_INITIALIZER_NP)
> + // Use an error-checking mutex type when assertions are enabled.
> + __native_type _M_mutex = PTHREAD_ERRORCHECK_MUTEX_INITIALIZER_NP;
> +# else
> __native_type _M_mutex = __GTHREAD_RECURSIVE_MUTEX_INIT;
> +# endif
I think this is incorrect.
If you try to lock an error-checking mutex recursively, the operation
fails, and it does *not* increment the internal lock counter (the mutex
may not even have one). This means a subsequent unlock operation will
release the mutex too early.
The trylock will be have differently, too.
POSIX recursive mutexes are already error-checking in that sense
(self-deadlock cannot happen, and an unlock when not lock is defined to
return an error), so I don't think anything like that is even needed.
Florian Weimer / Red Hat Product Security