public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug libstdc++/47354] New: bitmap_allocator free_list::_M_get never locks mutex
@ 2011-01-18 23:16 greed at pobox dot com
  2011-01-19  0:59 ` [Bug libstdc++/47354] " redi at gcc dot gnu.org
                   ` (13 more replies)
  0 siblings, 14 replies; 15+ messages in thread
From: greed at pobox dot com @ 2011-01-18 23:16 UTC (permalink / raw)
  To: gcc-bugs

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.


^ permalink raw reply	[flat|nested] 15+ messages in thread
end of thread, other threads:[~2011-01-27 15:22 UTC | newest]

Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-01-18 23:16 [Bug libstdc++/47354] New: bitmap_allocator free_list::_M_get never locks mutex greed at pobox dot com
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

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).