[Bug libstdc++/71684] Memory leak with std::mutex and std::lock_guard on freebsd

["nsz at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71684

--- Comment #5 from nsz at gcc dot gnu.org ---
(In reply to Jonathan Wakely from comment #3)
> (In reply to nsz from comment #1)
> > on a posix platform pthread_mutex_destroy should be called for a mutex if
> > its life time ends, so the ifdef logic seems wrong (the initializer does not
> > make a difference).
> 
> I don't think that's clear from the POSIX spec. In previous versions
> PTHREAD_MUTEX_INITIALIZER was only specified to be valid for statically
> allocated objects, which live for the lifetime of the program and so there's
> typically no need (or sensible time) to destroy them.
> 
> http://austingroupbugs.net/view.php?id=70#c127 changed the rules
> so now you can use the initializer for automatic objects, and structure
> members, but it's unclear whether you do need to use pthread_mutex_destroy
> on them.
> Maybe POSIX should clarify.
> 

i see.

> On some older versions of FreeBSD using PTHREAD_MUTEX_INITIALIZER and then
> pthread_mutex_destroy would segfault, see
> http://lists.freebsd.org/pipermail/freebsd-threads/2010-September/004905.html
> 
> So it's not clear to me that using that combination is a good idea.

in the current spec PTHREAD_MUTEX_INITIALIZER must have the same effect as
pthread_mutex_init(&m,0) without error checks, which means
pthread_mutex_destroy should work accordingly (and indeed pthread_mutex_lock
should not fail with ENOMEM either).

so this may need platform specific workarounds.