On Apr 3, 2013, at 11:47 AM, Derek Gaston <fried...@gmail.com> 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);
------------------------------------------------------------------------------
Minimize network downtime and maximize team effectiveness.
Reduce network management and security costs.Learn how to hire
the most talented Cisco Certified professionals. Visit the
Employer Resources Portal
http://www.cisco.com/web/learning/employer_resources/index.html
_______________________________________________
Libmesh-devel mailing list
Libmesh-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libmesh-devel
