On Apr 14, 2012, at 3:55 PM, Tom Browder wrote:

> I'm seeing some similarities between a failure in g-nff and other,
> similar tesselating converters.  On the same .g file, some bomb and
> throw "(BRL-CAD)-nnnnn-bomb.log", and some don't. but they all seem to
> fail on the same region.

The NMG processing can throw a bu_bomb() during tessellation.  Converters 
written to take that into consideration catch the bomb (ignoring the object 
failure) and proceed with other objects.   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.

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

Not sure I get what you're asking.  The logging behavior can be handled in code 
by writing and registering a callback function with libbu; the bombing behavior 
can be caught (see BU_SETJUMP conditionals in g-nff.c for an example).  Outside 
of the program, you can redirect stderr (2>file) to capture bu_log/bu_bomb 
output.  If you set the BU_DEBUG_ATTACH (0x00000080) libbu flag (e.g., rt's -! 
option) for applications that provide an option for editing bu_debug, that will 
pause the application during any bombs that would result in a backtrace (so you 
can manually attach a debugger).

> And does anyone mind if I change the "(BRL-CAD)-nnnnn-bomb.log" to
> "BRL-CAD-nnnnn-bomb.log" (because the parens aren't pleasant for a
> *nix file system)?

That's just the BRL-CAD (LIBBU) default for an unknown program name.  If you 
add a bu_setprogname(argv[0]) call in main(), it should set the program name so 
you'll get something like g-nff-123123-bomb.log instead of the generic default. 
 Otherwise, the  parens were intentional to not conflict with future plans.

Cheers!
Sean


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

Reply via email to