Thank you everyone for your pointers and suggestions. Luckily, I've ran into what looks like the same issue with a smaller testcase (the original reduced one was about 5MLOC compiled code with many shared libraries (linking statically or trying to remove any one of the shared libraries made the deadlock go away). The new testcase is much smaller and seems quite a bit simpler to reduce. It needs -fsanitize=undefined to trigger though, but I don't think the sanitizer is the issue here. Rather, it may only be a vehicle to turn on threading support (see below). Following Alexander's advice, the deadlock does not happen with -fno-guess-branch-probability, even with -O3, for what it's worth. Also, it only deadlocks in 32 bit mode. Jeff: I didn't mention it in my original email but the code is single threaded. I believe that the reason why a mutex is taken at all (in the new testcase) is that libubsan.so is linked against libpthread which would trigger the runtime detection mechanism for threaded support. Alexander: I don't remember where I learnt about -Q (perhaps by reading the gcc list?). Thanks, /Johan On Fri, Sep 25, 2015 at 11:55 AM, Jeff Law <law@xxxxxxxxxx> wrote: > On 09/24/2015 03:40 PM, Johan Alfredsson wrote: >> >> Hi, >> >> I have come across something which I believe is a bug in g++. I've >> seen this issue both in 4.9.1 and 5.2.0, but I'm struggling to create >> a small testcase. (The output of g++ -v for 5.2.0 is below.) >> >> The issue is a deadlock that seems to be due to there being (runtime) >> the equivalent of _two_ different variables __gthread_active_ptr. It >> just so happens that in the libstdc++ pool allocator template, the >> allocate() function, for a certain instantiation, is compiled so that >> the lock() method of the __scoped_lock (in ext/concurrence.h) is >> getting 'true' as the result of its call to __gthread_active_p(), >> while in the unlock() method it gets 'false'. The next allocation of >> the same type will of course deadlock due to not releasing the mutex >> after the previous allocation. > > For a locking or race condition issue, you might consider using hellgrind to > gain an understanding of what's going wrong without having to further reduce > the source. Once you have that understanding, it may be possible to show > the problem with simpler source or just explain what's going wrong (if > indeed it is a compiler issue). > >> >> Looking at the assembly code, in the unlock() method the code >> >> if (__gthread_active_p()) >> >> is actually reduced to >> >> mov $0x0,%eax >> test %eax,%eax >> >> so somehow g++ managed (erroneously) to fold this runtime-test during >> compile time (at least that is my guess). In the lock() method it >> looks like this: > > That would be an indication that the compiler thinks all the other tests > were redundant. The compiler is quite aggressive at trying to track this > kind of stuff. > > jeff >
