public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "greed at pobox dot com" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug libstdc++/47354] New: bitmap_allocator free_list::_M_get never locks mutex Date: Tue, 18 Jan 2011 23:16:00 -0000 [thread overview] Message-ID: <bug-47354-4@http.gcc.gnu.org/bugzilla/> (raw) http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47354 Summary: bitmap_allocator free_list::_M_get never locks mutex Product: gcc Version: 4.5.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassigned@gcc.gnu.org ReportedBy: greed@pobox.com Created attachment 23023 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23023 Add a mutex lock step in bitmap_allocator.cc On AIX, I received a test failure in ext/bitmap_allocator/variadic_construct.cc. terminate called after throwing an instance of '__gnu_cxx::__concurrence_unlock_ error' what(): __gnu_cxx::__concurrence_unlock_error FAIL: ext/bitmap_allocator/variadic_construct.cc execution test I was able to trace this back to src/bitmap_allocator.c free_list::_M_get, which unlocks its mutex, and that unlock causes the abort. It seems, however, that no code path ever locks the mutex in the first place. (The other use of the mutex use the __scoped_lock type, which does lock.) Linux allows you to unlock a mutex that was never locked. AIX, at least 5.3 TL4, gives you EINVAL when you attempt that. But, it seems to me that the mutex should be locked. To this end, I propose the (very simple) patch attached, which simply adds __bfl_mutex.lock() inside the #ifdef block. I have inspected the 'trunk' versions of src/bitmap_allocator.cc and include/ext/bitmap_allocator.h and believe that the problem remains in the trunk, not just 4.5.2.
next reply other threads:[~2011-01-18 21:43 UTC|newest] Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top 2011-01-18 23:16 greed at pobox dot com [this message] 2011-01-19 0:59 ` [Bug libstdc++/47354] " redi at gcc dot gnu.org 2011-01-19 1:25 ` paolo.carlini at oracle dot com 2011-01-19 1:31 ` redi at gcc dot gnu.org 2011-01-19 1:45 ` paolo.carlini at oracle dot com 2011-01-19 1:49 ` redi at gcc dot gnu.org 2011-01-19 2:27 ` redi at gcc dot gnu.org 2011-01-19 3:31 ` [Bug libstdc++/47354] [4.3/4.4/4.5/4.6 Regression] " redi at gcc dot gnu.org 2011-01-19 3:59 ` redi at gcc dot gnu.org 2011-01-19 4:37 ` [Bug libstdc++/47354] [4.3/4.4/4.5 " redi at gcc dot gnu.org 2011-01-19 9:00 ` redi at gcc dot gnu.org 2011-01-19 9:09 ` redi at gcc dot gnu.org 2011-01-19 9:54 ` [Bug libstdc++/47354] [4.3 " redi at gcc dot gnu.org 2011-01-27 14:44 ` paolo.carlini at oracle dot com 2011-01-27 15:41 ` greed at pobox dot com
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=bug-47354-4@http.gcc.gnu.org/bugzilla/ \ --to=gcc-bugzilla@gcc.gnu.org \ --cc=gcc-bugs@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).