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

[Tim Tautges]

So this is the heart of the issue, that things controlling the data layout in this class are changing from the 
compilation of the library vs. the compilation of the application using one of the class headers from the library.  What 
Jason/others suggest will work, i.e. getting rid of the #ifdef and just using a forward declaration of RefFace*; my 
question is, how is that used inside dagmc, i.e. is there a function that passes a RefFace* through the interface?

As an aside, I'd assert that the application's files depending on dagmc should probably depend on moab.make as well as 
on DagMC.hpp; that way any changes to the configuration will cause a recompile.  Comments?

- tim

On 06/24/2010 08:57 AM, Steve Jackson wrote:
>
> 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.  :)

-- 
================================================================
"You will keep in perfect peace him whose mind is
   steadfast, because he trusts in you."               Isaiah 26:3

              Tim Tautges            Argonne National Laboratory
          (tautges at mcs.anl.gov)      (telecommuting from UW-Madison)
          phone: (608) 263-8485      1500 Engineering Dr.
            fax: (608) 263-4499      Madison, WI 53706