On Thu, 2008-06-05 at 14:39 -0400, Alan Conway wrote: > Andrew Stitcher wrote: > > On Thu, 2008-06-05 at 19:31 +0200, Manuel Teira wrote: > >> ... > >> initMutexattr[1](once: 0xffffffff7e14e300, mutexattr: 0xffffffff7e1535f8) > >> initMutexattr[1](once: 0xffffffff7e14e620, mutexattr: 0xffffffff7e1535d8) > >> Mutex::Mutex with mutex at 0xffffffff7e14e680 and pthread_mutex_attr_t > >> at 0x0000000100400758 > >> Error initializing mutex: 0xffffffff7e14e680. Error 0 > >> AllThreadsStatuses ctor. Mutex: 0xffffffff7e14e680 > >> > >> [snip lots of other initMutexattr and Mutex::Mutex nonrelated calls] > >> initMutexattr[1](once: 0x00000001003f7730, mutexattr: 0x0000000100400758) > >> > >> > >> I suspect that the static nature of AllThreadStatuses could be involved. > >> Any thought? > > > > I'm pretty sure you are correct about the static initialisation order. > > > > One problem that your trace points out though is that we will get a > > _different_ initialisation for each file including Mutex.h due to the > > anonymous namespace used here - this wasn't the intention of this code. > > I guess this needs to be fixed by creating a Mutex.cpp to hold this > > anonymous namespace. However I'm not sure whether or not this is the > > cause of your problem,although it can't help. > > > > I think I may see the problem. Is all AllThreadsStatuses called (directly or > indirectly) from static constructors in other compilation units? > > An object that is called from static constructors in other compilation units > has > to be written in a rather special way - it has to be a POD and be POD > initialized - i.e. no constructors or destructors and no members/bases with > ctors/dtors.
It's the mutexattr static constructor that is the problem - that needs to be written as a singleton and as I said before moved into an implementation file. > > We have a PODMutex for exactly that situation PODMutex is currently useless (and isn't used anywhere as far as I know) because it can't create a recursive mutex which is what Mutex is. A piece of work we still need to do is to create a RecursiveMutex and revert Mutex to non recursive then only make mutexes recursive that have to be - then PODMutex might be useful again. > > Andrew do you know the circumstances under which this is called? Manuel - can > you post a stack trace? That should answer the question. I think that fixing Mutex so that its contructor can be safely called from anywhere in static initialisation is the way to go here. I think that the other issues are consequences of this lack. The problem is exacerbated because there are multiple initialisations of the mutexInitAttr one for every implementation file which uses Mutex so it almost bound to fail in this way - it's amazing we've not seen it before. Andrew > > Cheers, > Alan.
