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?
Thanks,
Derek
------------------------------------------------------------------------------
Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
Get 100% visibility into your production application - at no cost.
Code-level diagnostics for performance bottlenecks with <2% overhead
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap1
_______________________________________________
Libmesh-devel mailing list
Libmesh-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libmesh-devel
