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