Wait - are you using the very latest from GitHub Andrew? We had this issue a little while ago... but I was pretty sure it was fixed now...
Derek On Tue, Aug 6, 2013 at 3:50 PM, Roy Stogner <[email protected]>wrote: > > That's pretty baffling. We construct a singleton RemoteElem object > (which like any other new Elem should get a NULL _children member), > then when it's time to destruct it, _children is non-NULL? > > I've no idea how this could happen (especially in such a way that it > wouldn't affect *everyone*). The only thing I can think of to do with > debugging it is to step through the program and figure out where that > remote_elem->_children pointer gets set non-NULL. Unfortunately that > wouldn't be a very fun process, and it's not one that we can help you > much with since we can't replicate the problem. > --- > Roy > > > > On Tue, 6 Aug 2013, Andrew Davis wrote: > > Hey, >> >> Thanks! Yes rebuilding with gdb helps with the backtrace information. >> Now when I run the same program I still get >> a seg. fault but the backtrace info in gdb is >> >> #0 __GI___libc_free (mem=0x1) at malloc.c:2968 >> #1 0x000000000046219c in libMesh::Elem::~Elem (this=0x6c11e0, >> __in_chrg=<optimized out>) at >> /scratch1/local/include/**libmesh/elem.h:1336 >> #2 0x00007ffff6b701ca in libMesh::RemoteElem::~**RemoteElem >> (this=0x6c11e0, __in_chrg=<optimized out>) at >> src/geom/remote_elem.C:60 >> #3 0x00007ffff6b70236 in libMesh::RemoteElem::~**RemoteElem >> (this=0x6c11e0, __in_chrg=<optimized out>) at >> src/geom/remote_elem.C:65 >> #4 0x00007ffff67e1bf9 in libMesh::Singleton::cleanup () at >> src/base/libmesh_singleton.C:**108 >> #5 0x00007ffff67c2542 in libMesh::LibMeshInit::~**LibMeshInit >> (this=0x7fffffffe100, __in_chrg=<optimized out>) at >> src/base/libmesh.C:548 >> #6 0x0000000000457a2f in main (argc=1, argv=0x7fffffffe238) at >> /scratch1/davisad/software/**muq-ice/modules/RunTests.cpp:**18 >> >> Is this more informative to you? >> >> Thanks, >> Andrew >> >> >> On Tue, Aug 6, 2013 at 3:01 PM, Roy Stogner <[email protected]> >> wrote: >> >> Start by building (or rebuilding just your test program) in debug >> mode; if you're using opt then it's nearly impossible to pull >> helpful >> information out of gdb. >> --- >> Roy >> >> >> >> > > ------------------------------------------------------------------------------ > Get 100% visibility into Java/.NET code with AppDynamics Lite! > It's a free troubleshooting tool designed for production. > Get down to code-level detail for bottlenecks, with <2% overhead. > Download for free and get started troubleshooting in minutes. > http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk > _______________________________________________ > Libmesh-users mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/libmesh-users > > ------------------------------------------------------------------------------ Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk _______________________________________________ Libmesh-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/libmesh-users
