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

[Tom B. <tom...@gm...>]

On Sun, Apr 15, 2012 at 08:34, Christopher Sean Morrison <br...@ma...> wrote:
...
> 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.

Good advice.

> 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 looks like the situation here.

>> 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).

Aha!

> 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.

Definitely describes the situations.

Thanks, Sean.

Best,

-Tom