On Thu, 13 May 2010 08:40:22 -0600, Cody Permann <codyperm...@gmail.com> wrote: > On May 13, 2010, at 8:04 AM, Roy Stogner wrote: > > > > > On Thu, 13 May 2010, Cody Permann wrote: > > > >> I'm just curious what the developers know about the "print_trace" > >> functions in libMesh. > > > > It's just something I added a few years back to make debugging > > unexpected assertion failures (of both the libmesh_assert() and > > libmesh_error() forms) easier. I had been finding that line number > > info usually wasn't sufficient without knowing which higher level > > function (and sometimes which rank) called that line. > > This is exactly the boat we find ourselves in. Yeah we hit some error > which we obviously anticipated when we wrote the code but why and > where when you have these things scattered all over the code?
PETSc (in debug mode) keeps track of it's own stack for exactly this purpose (and related things like checking memory leaks with -malloc_dump). That is a bit heavyweight, a lighter alternative is -on_error_attach_debugger (PetscAttachDebuggerErrorHandler()) which will get you your trace and more on whichever process goes down, without running the whole code in a debugger or needing to write a full core dump (super slow for bigger problem sizes). Jed ------------------------------------------------------------------------------ _______________________________________________ Libmesh-devel mailing list Libmesh-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libmesh-devel
