From: Kirk, B. (JSC-EG311) <ben...@na...> - 2013-04-03 16:54:05
|
On Apr 3, 2013, at 11:47 AM, Derek Gaston <fri...@gm...> wrote: > I can't see how the container is not created yet... that would be a segfault when you try to push_back on it.... not too mention that the code that actually does the pushing back is in Singleton.C which is where the container is... so it would have had to have been created by the time you call that function… That was my thinking - that by putting the constructor implementation in the same translation unit as the buffer we should be fine… which leaves only the possibility that RemoteElemSetup is somehow not properly calling he Singleton::Setup base class constructor? Can you apply this on the affected systems and make sure that's not the case? diff --git a/src/base/libmesh_singleton.C b/src/base/libmesh_singleton.C index 977c743..8390db5 100644 --- a/src/base/libmesh_singleton.C +++ b/src/base/libmesh_singleton.C @@ -20,6 +20,7 @@ // Local includes #include "libmesh/libmesh_singleton.h" #include "libmesh/threads.h" +#include "libmesh/print_trace.h" // C/C++ includes #include <vector> @@ -63,6 +64,7 @@ namespace libMesh Singleton::Setup::Setup () { + print_trace(); SingletonMutex::scoped_lock lock(setup_mtx); setup_cache.push_back (this); |