[MOAB-dev] r4016 - MOAB/trunk/tools/dagmc

[Steve Jackson]

On Jun 23, 2010, at 23:46 , Tim Tautges wrote:
> As for the difficulty of tracking this down, did you try running this under valgrind?  That should warn about the RefXxx being referenced before being set.

Valgrind didn't help on this problem-- nothing was being 'referenced before being set.'  What was happening was that the client code expected a different memory layout for the DagMC object than the library code expected.  The various getFoo() methods defined in the DagMC header were therefore returning wrong values.  This led to bizarre behavior: sometimes DAG-MCNP crashed, sometimes it computed garbage, sometimes it ran correctly, and sometimes it ran correctly but took about 50 times longer to execute than expected [1].  These behaviors changed if I added additional dummy variables in the DagMC object (thus changing its memory layout).  Even when the program crashed, valgrind and gdb weren't very helpful-- the crashes usually happened inside the Fortran client code, and were related to bogus values that had been returned from DagMC (perhaps long before the actual error).

What I ultimately discovered (using gdb) was that the memory addresses of DagMC member variables were different when the program was operating in the context of library code vs. inside the context of application code.  And then I remembered the #ifdef.

Regarding moab.make: I realize it's always recommended to pull this file into client makefiles.  But up to now, doing that hasn't been *required* for correct compilation, and I would hesitate to create that requirement, particularly given the confusing failure mode described above.  (Usually if you don't use moab.make correctly, you merely get linker errors.)

If the present solution is too ugly, then I prefer Jason's idea of setting up a DAGMC_HAVE_CGM macro through AC_CONFIG_HEADERS, so that the client can just include DagMC.hpp and have everything work correctly.  I also agree that "CGM" is too general a macro name to export to clients.
~S

[1]: I didn't take the time to diagnose this odd slowdown, but I'm privately hoping it happened because the client code got confused into calling point_in_volume_slow() instead of point_in_volume()-- an unlikely scenario, but it would be amusing.  :)