testCascade and cascade_example segfault in release-type build

If I compile a release build with g++ 8.2.1, I get segfaults when executing testCascade and cascade_example. No issues with clang though. gdb says it happens in TrackingLine::GetTrack.

Furthermore, testSibyll seems to get stuck in some kind of endless loop (clang & g++). The output doesn't get beyond

Decay: calling Sibyll decay routine..

happens with -O1 or higher

If this is an optimization problem, is it possible to set the optimization flag separate for the external packages? I wouldn't consider Sibyll, Epos and co. save to use with anything but -O0. Sibyll at least is not tested with optimization.

The -Ox flags shouldn't cause different results at all, see https://stackoverflow.com/questions/13518759/secure-gcc-optimization-options-for-numerics. But yes, enabling/disabling optimization for different object files is possible.

This bug is very mysterious to me. We have all warning flags enabled and enforce strict standard compliance. I'll try to compile with icc on the BinAC cluster and see what happens there.

Optimization problems like this one are an excellent tool to find bugs otherwise hidden (looming, and ready to hit us in the future). See e.g. the checklist here: https://stackoverflow.com/questions/11423826/compiler-optimization-makes-program-crash

I switched off optimization just to prevent external testers to report to us what we already know. Besides this, we have to find the real cause of this crash and fix it! I would start to search for temporary objects going our of scope unnoticed. It could be that Particle& p = *Stack::GetNextParticle() etc. are potential problems, but this requires some systematic work investigating all use of pointers and references. I am sure afterwards the framework becomes even more clean and more stable.

Tests with optimized builds should be part of the CI setup to prevent us from running into an ambush like this again.

Good point. I even forgot that we distinguish between Debug and Release builds. At some point we need someone with time to work on the gitlab-ci in-depth. We need a matrix of systematic builds...

Before that, we have to investigate and find out what really happens. Maybe valgrind can help, too?

Btw. in #102 (closed) we had a very similar crash, which also affected gcc and not clang, and was induced by a dangling object reference.

added Critical label

changed milestone to %Physics demonstrator (hadron core)

assigned to @mreininghaus

The crash is related to the constructor

StackIteratorInterface::StackIteratorInterface(StackType&, const int)

If I just add a cout << "..." inside, no more crash.

Great work. This means it is related to either "producing" "deleting" "referring" "copying" or "pointing" to StackIteratorInterface (aka Particle) objects. We carefully have to check where in our workflow we do exactly what with StackIteratorInterface objects (it is obvious that the "cout" is not a fix, but just a distraction for the optimizer in gcc...)

Problems could come e.g. from "const casting", "temporary objects", or from changing the std::vectors used on the SuperSimpleStack while we still access a Particle object/reference (->the std::vector memory mapping changed).

Without the "fix", GetIndex() yields random results.

created branch 118-testcascade-and-cascade_example-segfault-in-release-type-build

mentioned in merge request !53 (merged)

closed via merge request !53 (merged)

mentioned in commit 48e45468

fixed with duct tape