In 4.3.1 (and 4.2.x and the trunk), ARM targets and no doubt plenty others use
libstdc++/config/cpu/generic/atomicity_mutex/atomicity.h.
With some build magic in libstdc++/src/Makefile.am, this file is also
atomicity.cc when building the library. Thus this object gets instantiated:
{
__gnu_cxx::__mutex atomic_mutex;
} // anonymous namespace
The constructor for __mutex in include/ext/concurrence.h has a private member
of the underlying __gthread_mutex_t, and its constructor uses
GTHREAD_MUTEX_INIT or calls GTHREAD_MUTEX_INIT_FUNCTION as appropriate, as of
course it should.
The problem is that this becomes a global constructor and there is no control
over where in the running of global constructors it gets run. A consequence of
this is that any other initialisation function from another constructor using
atomic operations can end up locking a mutex which has never been initialised,
with unsurprising results. An example of such a case is ios_base::Init::Init()
which calls __gnu_cxx::__exchange_and_add_dispatch() which eventually reaches
__gnu_cxx::__scoped_lock sentry(atomic_mutex); which attempts to lock
atomic_mutex.
Code prior to this implementation used __gthread_mutex_t in atomicity.h
directly using a macro defined by concurrence.h:
__glibcxx_mutex_define_initialized(atomic_mutex);
and as such this used to work, so this is a regression.
It seems this is an unintended consequence of this change:
http://gcc.gnu.org/ml/libstdc++/2006-09/msg00084.html
I think this needs returning to something similar to the way it was before, so
that the __gthread_mutex_t was created in the atomic_mutex's own constructor.
--
Summary: config/cpu/generic/atomicity_mutex/atomicity.h
incorrectly relies on global constructor ordering
Product: gcc
Version: 4.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jifl-bugzilla at jifvik dot org
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: arm-eabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36801
