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