I don't even have any ideas on what "this" is. They're seeing an
On Tue, 28 May 2013, Derek Gaston wrote:
A large project recently sucked in MOOSE (and therefore libMesh) into a much larger code-base... and they are seeing issues with the new singleton stuff.
Here's just a snippet from a debug build run through Valgrind.
==9467== Invalid write of size 8
==9467== at 0x61912DB: __gnu_debug::_Safe_sequence_base::_Safe_sequence_base() (safe_base.h:193)
==9467== by 0x9F0FB15: __gnu_debug::_Safe_sequence<std::__debug::map<int, unsigned int, std::less<int>, std::allocator<std::pair<int const, unsigned int>
> > >::_Safe_sequence() (safe_sequence.h:112)
==9467== by 0x9F0FB6C: std::__debug::map<int, unsigned int, std::less<int>, std::allocator<std::pair<int const, unsigned int> > >::map(std::less<int>
const&, std::allocator<std::pair<int const, unsigned int> > const&) (map.h:79)
==9467== by 0x9F0543F: libMesh::Parallel::Communicator::Communicator() (in /localhome/p8d/VERA/MOOSEExt/MOOSE/libmesh/installed/lib/libmesh_dbg.so.0.0.0)
==9467== by 0x9F01AF2: libMesh::LibMeshInit::LibMeshInit(int, char const* const*, ompi_communicator_t*)
Any ideas on stuff they can do to mitigate this?
invalid write from inside a *GLIBCXX_DEBUG* operation? The whole
point of debug mode is supposed to be catching STL errors before they
can get to that point!
I don't suppose we're lucky enough that you've been able to reproduce
this? If not then all I can think of to do is a valgrind runthrough
of our libMesh apps in the slim hope that one triggers the same