http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46455
Jonathan Wakely <redi at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Last reconfirmed| |2010.11.15 14:13:00
Ever Confirmed|0 |1
--- Comment #10 from Jonathan Wakely <redi at gcc dot gnu.org> 2010-11-15
14:13:00 UTC ---
(In reply to comment #9)
>
> this code produces the same behavior as my test case (increasing number of
> semaphores, over 100 after 10 seconds) on both vanilla MinGW and mingw64.
>
> to summarize: my test case (standard shared_ptr creation) worked fine on
> mingw64 (which has a __gnu_cxx::__default_lock_policy = 2) but bugged on
> vanilla MinGW (which has a __gnu_cxx::__default_lock_policy = 1); but this one
> produces the bug in both cases.
That's because my simpler test ignores the default_lock_policy, it always uses
a mutex, which is what shared_ptr does when __default_lock_policy=1
I've just looked at __gnu_cxx::__mutex and it doesn't have a destructor, so the
problem is probably just that we leak the mutex. This should show the same bug:
#include <ext/concurrence.h>
int main()
{
for (int i=0; i<100; ++i)
__gnu_cxx::__mutex m;
}
Could you test that?
We should add a destructor to __mutex, which calls __gthread_mutex_destroy.
N.B. this could cause a problem on FreeBSD
http://www.freebsd.org/cgi/query-pr.cgi?pr=150889
so we might want to only call __gthread_mutex_destroy when we have used
__GTHREAD_MUTEX_INIT_FUNCTION
