On Sat, Apr 14, 2012 at 22:09, Christopher Sean Morrison <[email protected]> wrote:
> On Apr 14, 2012, at 3:55 PM, Tom Browder wrote:
...
> Converters not written to catch bombs get the default handler
> behavior, which is to generate a bomb.log with a stack trace and
> then halt the application.
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.
>> Is there any way to turn off or change the behavior of bu_bomb/bu_log
>> for the converter programs so I can capture info from stderr and
>> stdout without bothering the executables internally? I know I can use
>> 'script' if I have to but would rather not.
I used script which worked okay.
> Outside of the program, you can redirect stderr (2>file) to
> capture bu_log/bu_bomb output.
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.
> If you set the BU_DEBUG_ATTACH (0x00000080) libbu flag
Thanks.
> If you add a bu_setprogname(argv[0]) call in main(),
> it should set the program name so you'll get something
Okay!
Cheers!
-Tom
------------------------------------------------------------------------------
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2
_______________________________________________
BRL-CAD Developer mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/brlcad-devel
