On Jan 10, 2011, at 11:40 AM, Roy Stogner wrote:



On Mon, 10 Jan 2011, Cody Permann wrote:

So I've been looking into making some of the error handling stuff
more robust on the Mac Platform, i.e. catching NaNs better and
better stack traces.  I was just looking through the print_trace.C
file and noticed that somebody has written wrappers for the
demangler and stack trace that seem to work just fine on the current
Mac platform with the Mac version of the g++ compiler.  However this
code is disabled in the print_trace file defaulting to the other
Linux code which doesn't demangle on the Macs.  Perhaps the Mac code
was never enabled because of inadequate testing or some other
problem?

s/inadequate testing/no testing/

When writing print_trace I found a couple references online to APIs
that purported to do the same stack grabbing and demangling on OSX
that we do on Linux; however at that time I didn't have an OSX libMesh
build and couldn't even test whether the code would compile or not.

Then when I finally got an OSX build, a year or two later, I didn't
think to go back and check whether the OSX print_trace would work or
not.


Unless somebody has a reason not to, I propose that we
enable that code again for the Mac platform.  I'll make the
necessary changes and will check it back in.

Thanks!

I'm also looking into catching NaNs sooner.  The current isNaN stuff
that Roy recently added doesn't work very well on the Mac Platform.
It appears that the g++ compiler on this platform doesn't honor
signaling nans even when using the appropriate compile flags
(-fsignaling-nans or -ftrapping_math).

Wait, I specifically avoided using g++ - the whole point of that one
.c file is to let us take advantage of the standard-in-C-but-not-C++
isnan() macro.  That macro doesn't work on OSX?

Sorry for the confusion - the isnan macro is working.  I was being more lazy than that.  In the past on other codes, I found it useful to to have signals generated when NaNs are generated/used.  This is something that can be control (in a somewhat non-portable way) through changing some processor control environment masks.  That way we could avoid scattering isnan through our applications down into our user codes, instead relying on signal handling to flag the point of generation/use.  We already have isnan in some key places in our debug builds but many times by the time we've hit those checks we don't know exactly where the nan was generated in the first place.  I'm after something a little different here.


I did find some Intel specific code using intrinsics that does work
though.

Silly question: does testing "x != x" work?  I think that's supposed
to be the most standard C++-only way to test isnan.

This usually works but again is an explicit check, something I was trying to avoid


The down side is that this code will only work on Mac Intel
processors which is a little less portable but probably not a big
issue.  If I find a portable way to add this to the library I will
do so.

Don't worry too much about portability in libmesh_isnan.c; the whole
reason for libmesh_isnan() to exist is to wrap a bunch of potentially
non-portable/hackish implementations into a single portable inline
function.

If I figure out this whole signal business that's the option i'd like to add.  It would have to be something that could easily be turned on/off and throw exceptions earlier and possibly without explicit isnan calls.


---
Roy