Segfault in dyninst when instrumenting boost

[skyreflectedinmirrors]

Due to #144, I noticed a segfault in dyninst when instrumenting boost inside in runtime instrumentation mode. This happens inside of the finalization of the dyninst instrumentation:

[omnitrace][exe]  769 instrumented funcs in picongpu
[omnitrace][exe]
[omnitrace][exe] Finalizing insertion set...
[TheraC18:73504:0:73504] Caught signal 11 (Segmentation fault: address not mapped to object at address (nil))
Segmentation fault (core dumped)

I am using my own boost, rather than building w/ Omni, as PIConGPU needs it as well (boost/1.75.0 built against gcc/8.3.0). This was also reported on Crusher though, so I doubt it's version specific

To repro:

export BASE_FOLDER=$(pwd)
export PICSRC=${BASE_FOLDER}/picongpu
export PIC_EXAMPLES=$PICSRC/share/picongpu/examples
export PIC_BACKEND="hip:gfx90a"

export PATH=$PATH:$PICSRC
export PATH=$PATH:$PICSRC/bin
export PATH=$PATH:$PICSRC/src/tools/bin


export PATH=$PATH:$PICSRC
export PATH=$PATH:$PICSRC/bin
export PATH=$PATH:$PICSRC/src/tools/bin

export CXX=hipcc
pic-create ${PICSRC}/share/picongpu/benchmarks/TWEAC-FOM/ fom
cd fom
pic-build -t 2

# run PIConGPU in aninteractive shell on one GPU for 100 steps and use GPU aware MPI (--mpiDirect)
omnitrace -v 3 -- ./bin/picongpu --mpiDirect -d 1 1 1 -g 240 272 224 --periodic 1 1 1 -s 100 -r 2

[jrmadsen]

This is interesting. It may simply be fixed by having the Dyninst submodule build boost bc I set it up to build and link to the static boost libraries so theoretically, if this is a case of self-instrumentation, it'll be resolved since it won't be using the boost symbol it instruments.

[jrmadsen]

It's interesting bc the Dyninst team said they want to get rid of the building dependencies support. But this would be a strong case keeping that if Dyninst needs a static boost lib to instrument binaries using boost libs

[jrmadsen]

I'm going to close this with the note that it is highly recommended to statically link boost, or at least compile boost with hidden visibility (I suspect that if your boost version was built with global visibility, could be an issue here since I think most Dyninst builds outside of omnitrace use shared boost libraries)