[Libmesh-devel] print_trace
I'm just curious what the developers know about the "print_trace" functions in libMesh. I decided to add that functionality to our applications here at the INL yesterday since we expended the use of libmesh_error greatly to the point where we need more contextual information. Derek and I noted the "MAC OS X" Code section near the bottom of that source file which is permanently disabled. Perhaps with a little background information, I might find some time to work on cleaning this up since I have access to plenty of Macs with both Intel and GNU compilers loaded. For now though the other implementation works on our Mac workstations when compiled in debug mode but doesn't demangle which is OK with the people that might actually look at those errors but if it's close to working then maybe I can assist in getting it the rest of the way there. Cody -- ___ Libmesh-devel mailing list Libmesh-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libmesh-devel
Re: [Libmesh-devel] print_trace
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. > I decided to add that functionality to our applications here at the > INL yesterday since we expended the use of libmesh_error greatly to > the point where we need more contextual information. Derek and I > noted the "MAC OS X" Code section near the bottom of that source > file which is permanently disabled. Yeah - I found some code online which supposedly did the same demangling job, but I couldn't test it myself since I didn't have any Mac libMesh builds then. > Perhaps with a little background information, I might find some time > to work on cleaning this up since I have access to plenty of Macs > with both Intel and GNU compilers loaded. For now though the other > implementation works on our Mac workstations when compiled in debug > mode but doesn't demangle which is OK with the people that might > actually look at those errors but if it's close to working then > maybe I can assist in getting it the rest of the way there. That would be great - not sure what I can provide you in the way of background info, though. The demangling APIs seem to be somewhat non-standardized voodoo. --- Roy -- ___ Libmesh-devel mailing list Libmesh-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libmesh-devel
Re: [Libmesh-devel] print_trace
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? > >> I decided to add that functionality to our applications here at the >> INL yesterday since we expended the use of libmesh_error greatly to >> the point where we need more contextual information. Derek and I >> noted the "MAC OS X" Code section near the bottom of that source >> file which is permanently disabled. > > Yeah - I found some code online which supposedly did the same > demangling job, but I couldn't test it myself since I didn't have any > Mac libMesh builds then. > >> Perhaps with a little background information, I might find some time >> to work on cleaning this up since I have access to plenty of Macs >> with both Intel and GNU compilers loaded. For now though the other >> implementation works on our Mac workstations when compiled in debug >> mode but doesn't demangle which is OK with the people that might >> actually look at those errors but if it's close to working then >> maybe I can assist in getting it the rest of the way there. > > That would be great - not sure what I can provide you in the way of > background info, though. The demangling APIs seem to be somewhat > non-standardized voodoo. Actually this is exactly what I was look for: "found some code online", "didn't have Mac libMesh builds" and "non-standardized voodoo". I just didn't want to dive into it if it had been disabled or never enabled in the first place if it had been done for some less obvious reason. > --- > Roy -- ___ Libmesh-devel mailing list Libmesh-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libmesh-devel
Re: [Libmesh-devel] print_trace
On Thu, 13 May 2010, Cody Permann wrote: Actually this is exactly what I was look for: "found some code online", "didn't have Mac libMesh builds" and "non-standardized voodoo". I just didn't want to dive into it if it had been disabled or never enabled in the first place if it had been done for some less obvious reason. No secret reason. Check the SVN logs to be sure, but IIRC I left the code in there commented to make it easy to enable that feature on Macs later, but didn't want to actually enable it myself unless I could properly test it. --- Roy-- ___ Libmesh-devel mailing list Libmesh-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libmesh-devel
Re: [Libmesh-devel] print_trace
On Thu, 13 May 2010 08:40:22 -0600, Cody Permann 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
