On Fri, 19 Apr 2013, Derek Gaston wrote:
Well - of course I spoke too soon. It just crashed again... but this time I
got a core dump....
check out the stack trace:
#0 variant_filter_iterator<libMesh::Predicates::multi_predicate,
libMesh::Elem* const,
libMesh::Elem* const&, libMesh::Elem*
const*>::Pred<__gnu_cxx::__normal_iterator<libMesh::Elem*
const*, std::vector<libMesh::Elem*, std::allocator<libMesh::Elem*> > >,
libMesh::Predicates::Local<__gnu_cxx::__normal_iterator<libMesh::Elem* const*,
std::vector<libMesh::Elem*, std::allocator<libMesh::Elem*> > > > >::operator()
(this=0x36d9f950,
in=<value optimized out>) at ./include/libmesh/variant_filter_iterator.h:298
#4 libMesh::SerialMesh::local_elements_begin (this=<value optimized out>) at
src/mesh/serial_mesh_iterators.C:333
#8 0x00002ae6c4724438 in libMesh::MeshBase::prepare_for_use (this=0x365fcee0,
skip_renumber_nodes_and_elements=<value optimized out>) at
src/mesh/mesh_base.C:133
It's impossible to tell for sure without more debugging options, but
I'd swear this looks like you've somehow got a stray Elem* (probably
pointing to uninitialized or freed memory) in that mesh.
This would be ugly, because if that's the case then you're not looking
at the bug, you're looking at the fallout from some
potentially-much-earlier bug. The only thing I can think to do
debugging-wise is throw around loops over local element iterators and
see where they first start triggering a segfault.
---
Roy
------------------------------------------------------------------------------
Precog is a next-generation analytics platform capable of advanced
analytics on semi-structured data. The platform includes APIs for building
apps and a phenomenal toolset for data science. Developers can use
our toolset for easy data analysis & visualization. Get a free account!
http://www2.precog.com/precogplatform/slashdotnewsletter
_______________________________________________
Libmesh-devel mailing list
Libmesh-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libmesh-devel
