This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug libstdc++/71684] Memory leak with std::mutex and std::lock_guard on freebsd
- From: "redi at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Tue, 28 Jun 2016 15:42:38 +0000
- Subject: [Bug libstdc++/71684] Memory leak with std::mutex and std::lock_guard on freebsd
- Auto-submitted: auto-generated
- References: <bug-71684-4 at http dot gcc dot gnu dot org/bugzilla/>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71684
Jonathan Wakely <redi at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Last reconfirmed| |2016-06-28
Ever confirmed|0 |1
--- Comment #2 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Phil Longstaff from comment #0)
> std::lock_guard constructor calls gthread_mutex_lock() which calls
> pthread_mutex_lock(), a 'struct pthread_mutex' will be created using
> calloc() and then locked.
I was made aware of this behaviour of FreeBSD recently, but I'm not sure that
it's conforming. pthread_mutex_lock() isn't allowed to fail with ENOMEM (and
EAGAIN is supposed to mean too many locks are held, not that memory couldn't be
allocated).
Conforming or not, we need to deal with it.