[MOAB-dev] r3273 - in MOAB/trunk: . tools/dagmc

Jed Brown jed at 59A2.org
Wed Nov 4 06:47:39 CST 2009


kraftche at cae.wisc.edu wrote:
> Author: kraftche
> Date: 2009-11-03 13:06:17 -0600 (Tue, 03 Nov 2009)
> New Revision: 3273
> 
> Modified:
>    MOAB/trunk/FileOptions.cpp
>    MOAB/trunk/FileOptions.hpp
>    MOAB/trunk/MBCore.cpp
>    MOAB/trunk/tools/dagmc/test_geom.cc
> Log:
> return error code if unrecognized options are passed to load_file or write_file


As you probably know, this breaks a ton of parallel tests.


When checking that it wasn't just a local problem, it occurred to me
that MOAB is obnoxiously difficult to debug.  This is largely due to the
fact that there is no obvious point to attach a debugger to see when an
error first occurs.  Instead, user code gets a helpful MB_FAILURE, and
*my* error handler lets me easily have the debugger at this point.  But
finding the first place that the error occurs is really slow because I
have to deal with it one stack frame at a time, either by stepping or
bisecting at each frame.  (GDB's new "reverse-debugging" can help, but
it's finicky.)  In contrast, when PETSc reports an error, I get a full
stack trace (without the debugger) and I can immediately have a debugger
on the line where the error first occurred (literally 1-5 seconds from
"look, there's an error" to a debugger on the relevant line, even in
parallel).

Having MOAB print it's own stack trace would take significant work, but
allowing a user-defined error handler is simple (it would touch a lot of
code, but not in an interesting way) and would help a lot.  The main
difficulty is that MBErrorCode is also used to return non-error
conditions, therefore the error handler cannot just dump core or attach
debuggers, it needs to first decide whether the error was intentional.

Jed

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 261 bytes
Desc: OpenPGP digital signature
URL: <http://lists.mcs.anl.gov/pipermail/moab-dev/attachments/20091104/664f26da/attachment-0001.pgp>


More information about the moab-dev mailing list