Re: [brlcad-devel] Debugging g-nff and Friends

[Christopher S. M. <br...@ma...>]

On Apr 15, 2012, at 6:53 AM, Tom Browder wrote:

> Well, g-nff does have a handler ("try/catch") but the failure (a bad
> tree struct after the boolean functon) isn't being handled. I'll check
> the others Ilisted, to see if it's the same problem.

There are certainly places and situations where a bomb might not be caught (such as during the 'catch' or outside the try/catch).  Would be helpful to see the stack trace in that case to see where exactly it was during execution.

There are possibly some outlier situations too like calling multiple try/catch within a try where an internal exception might get caught disabling the top-level try/catch.  The problem from an implementation standpoint is that the NMG code is very bomb-happy and uses it as part of normal processing instead of error code propagation.  The code should be changed to only bomb on critical memory failures (and not try/catch within itself).

> That is what gets me--it doesn't work.  It's like there's a third
> stream which goes to the terminal no matter what.

There is exactly that for a bomb that is tearing down an application.  Given they're considered a non-normal abort (basically a graceful crash), every attempt is made to let the user know what happened which includes printing directly to /dev/tty (which cannot be captured).

Note that only happens when 1) there is no log handler and 2) there is no jump (try/catch) set.  The application is going down in a (controlled) blaze of glory.

Cheers!
Sean