This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug libstdc++/51906] thread lock test failures on darwin11 under Xcode 4.2
- 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: Sat, 28 Jan 2012 19:16:37 +0000
- Subject: [Bug libstdc++/51906] thread lock test failures on darwin11 under Xcode 4.2
- Auto-submitted: auto-generated
- References: <bug-51906-4@http.gcc.gnu.org/bugzilla/>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51906
--- Comment #13 from Jonathan Wakely <redi at gcc dot gnu.org> 2012-01-28 19:16:37 UTC ---
(In reply to comment #12)
> The contents of 3.ii.diff seems to suggest that the problem is the fact that
> Lion always defines _GTHREAD_RECURSIVE_MUTEX_INIT and this support is either
> buggy on Lion or is exposing a libstdc++ mutex bug.
libstdc++ really isn't doing anything complicated here, you should be able to
reproduce the problem with a minimal testcase using pthreads directly
#include <pthread.h>
struct mutex {
pthread_mutex_t m = PTHREAD_RECURSIVE_MUTEX_INITIALIZER;
};
int main()
{
mutex m;
pthread_mutex_lock(&m.m);
}
It would also help to see a stack trace for where the tests hang (although I'm
guessing it's when calling pthread_mutex_lock, so I expect the code above to
have the same problem)
It's possible this is another instance of the same problem as PR 51296, i.e.
the pthreads mutex init macros are only required to work for
statically-allocated mutexes, not automatic variables.