So after reverting the version of backward to the current one, I managed to link it to backward_object and it works correctly in this branch: https://github.com/gazebosim/gz-sim/tree/arjo/properly_segfaults_w_stacktrace

I don't think the above branch has the ideal solution however. TBH the CMake-fu going on in the library exceeds my domain of knowledge. One option is to get rid of all the cmake stuff and only include the header. we can manually instantiate BackwardHandle in the C++ binary.

I think whats happening is that Backward::Backward is getting optimized out since we dont use it in our code.

LMK what you think @j-rivero

I tried this branch and introduced a segfault, however the stack traces are not being printed.

Makes sense. The build log does not display any modifcation of code being done by the linker. re-reading the backwards-cpp lib instructions we can use either the header file or the .cpp file. I think that you are using the later when linking against backwards_object target. I would prefer to keep the installation more standard by using the header and the Backwards::Backwards CMake target.

Said that, I've brought the backwards-cpp code into the main/gui in 42383a5 by including the headers and the signal handler. Segfaulting on propose triggers clear stacktraces on my system after using RelWithDebInfo.

This works great for the binaries but introduces a regression on the tests where segfaulting tests no longer print stack traces.

You are right. I've reverted the usage of the header-only files, I think that it is more intrusive for the code 255dd43.

For using the linking approach and the "object" CMake target we need to stop using the find_package and use the add_subdirectory as detailed in the backwards-cpp README. Changing that and using Backwards::Object was good enough for the binaries.

For the special case of EXTRA_TEST_LIB_DEPS I think that CMake is not resolving properly that CMake Backwards::Object so I used the backward_object instead.

Seems good enough for me after tesing tests and binaries 0109512

Ubuntu servers are having a bad day. To merge the PR I wanted to give a look into how much overload in time we are adding with this PR.

Comparing a couple of build from the same day, 28 May:

• https://build.osrfoundation.org/job/gz_sim-ci-pr_any-noble-amd64/788/ backwards-cpp 46min
• https://build.osrfoundation.org/view/gz-jetty/job/gz_sim-ci-main-noble-amd64/119/ main 42min

Let's see if we can get data from today builds when servers are back.