Created attachment 23023 [details] 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.
I wouldn't be surprised if that code has bit-rotted, I'll check it out now ...
Thanks for checking Jon. If we can't fix the issue very quickly, I vote for simply removing that specific allocator, it never worked very well and the code itself is rather ugly, IMHO.
Comment on attachment 23023 [details] Add a mutex lock step in bitmap_allocator.cc the patch looks correct
Great.
Revision 116942 removed the lock - I'm testing the fix now
Confirmed by modifying __gnu_cxx::__mutex to use PTHREAD_ERRORCHECK_MUTEX_INITIALIZER_NP to initialize the mutex: $ lib0x ./var terminate called after throwing an instance of '__gnu_cxx::__concurrence_unlock_error' what(): __gnu_cxx::__concurrence_unlock_error Aborted (core dumped)
this is a regression in all active branches rather than modifying the source to use an error-checking mutex, valgrind's drd tool can be used to show it was ok in 4.1 and is wrong in gcc 4.2+ ==6026== drd, a thread error detector ==6026== Copyright (C) 2006-2010, and GNU GPL'd, by Bart Van Assche. ==6026== Using Valgrind-3.6.0 and LibVEX; rerun with -h for copyright info ==6026== Command: ./a.out ==6026== ==6026== The object at address 0x4f0f780 is not a mutex. ==6026== at 0x4A11932: pthread_mutex_unlock (drd_pthread_intercepts.c:640) ==6026== by 0x4C6F8BD: __gnu_cxx::free_list::_M_get(unsigned long) (gthr-default.h:790) ==6026== by 0x4021E0: __gnu_cxx::bitmap_allocator<int>::_S_refill_pool() (in /dev/shm/a.out) ==6026== by 0x401A38: __gnu_cxx::bitmap_allocator<int>::_M_allocate_single_object() (in /dev/shm/a.out) ==6026== by 0x40178E: __gnu_cxx::bitmap_allocator<int>::allocate(unsigned long) (in /dev/shm/a.out) ==6026== by 0x400CDD: main (in /dev/shm/a.out)
Author: redi Date: Wed Jan 19 02:27:45 2011 New Revision: 168980 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=168980 Log: 2011-01-19 Graham Reed <greed@pobox.com> PR libstdc++/47354 * src/bitmap_allocator.cc (free_list::_M_get): Lock mutex. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/src/bitmap_allocator.cc
fixed on trunk so far
Author: redi Date: Wed Jan 19 08:49:58 2011 New Revision: 168985 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=168985 Log: 2011-01-19 Graham Reed <greed@pobox.com> PR libstdc++/47354 * src/bitmap_allocator.cc (free_list::_M_get): Lock mutex. Modified: branches/gcc-4_5-branch/libstdc++-v3/ChangeLog branches/gcc-4_5-branch/libstdc++-v3/src/bitmap_allocator.cc
Author: redi Date: Wed Jan 19 08:50:29 2011 New Revision: 168986 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=168986 Log: 2011-01-19 Graham Reed <greed@pobox.com> PR libstdc++/47354 * src/bitmap_allocator.cc (free_list::_M_get): Lock mutex. Modified: branches/gcc-4_4-branch/libstdc++-v3/ChangeLog branches/gcc-4_4-branch/libstdc++-v3/src/bitmap_allocator.cc
fixed for 4.4.6 and 4.5.3 too
I guess we can close this as fixed, at this point nobody really cares about this rather unused allocator in 4.3.x.
I agree; thanks guys.