I’ve been struggling with inconsistent behaviour in my user application (specifically, my ConstructSDandField() was instantiating the wrong SD type for certain job configurations). From running in GDB, it seems as though there are memory problems of some kind that cause this inconsistent behaviour (but no segfaults, and the final application output seems reasonable).
I’ve finally managed to isolate the situation where my error occurs from the situation where it doesn’t, and it makes no sense to me.
We have two builds of G4 10.07.p04 installed. One was built with CMAKE_RELEASE_TYPE=Release, and the other was built with CMAKE_RELEASE_TYPE=Debug and G4DEBUG=ON. If I compile and link my use application against the “Release” version, then I get the incorrect behaviour. Compiling and linking the identical code against the “Debug” build behaves exactly as expected.
Is there anything between those two build types that would change the memory layout of either user classes or Geant4 base classes?
From a non-exhaustive look through the CMake/C++ in that version, I can’t spot anything obvious that’s configured (e.g. via #ifdefs and the like) differently depending on the build type.
Others may chip in, otherwise have you tried the intermediate “RelWithDebInfo” build mode? That uses -O2 -g so comparing that with Release (-O3) and Debug (no optimization at all) might give a hint if it’s optimization related. Have you also tried building/linking to the Release install of Geant4 with a Release build of the application (and various permutations thereof)? Nominally that’s usually only an issue on Windows, but might be another thing to compare.
Thank you, Ben. I didn’t find anything either. Only G4InteractionContent.hh contains a use of #ifdef G4DEBUG, which wraps a non-virtual function, so that wouldn’t affect the class layout.
I have tried different combinations of Release vs. Debug between the application and G4. We also make use of LMod modules on my cluster, so I’ve also tried building with one G4 module, and running with another.
It’s the module-based builds of our application that show the problem, where (in all but a single case) my personal direct builds are fine. Your suggestion about seeing how RelWithDebInfo behaves is interesting; I’ll give that a try.