We run all of our tests through Valgrind for every change - so it's not a normal thing.  Definitely something to do with the way they're linking stuff together....

Ben - are you saying I need to apply that patch?  Has that patch been removed - I thought that was still in there right now....


On Tue, May 28, 2013 at 1:15 PM, Roy Stogner <roystgnr@ices.utexas.edu> wrote:

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?

I don't even have any ideas on what "this" is.  They're seeing an
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