backwards-cpp support for gz-sim-main and gz-sim-gui

[j-rivero]

🎉 New feature

Closes #2906

Summary

The PR adds support for backwards-cpp in gz-sim-main and gz-sim-gui. To do so:

• Bump backwards vendor to 1.6 5913812
• Relocate the backwards vendor directory outside of the root to be used by CLI 965d463
• Build binaries with backwards support fd0edc9

Checklist

• Signed all commits for DCO
• Added tests
• Added example and/or tutorial
• Updated documentation (as needed)
• Updated migration guide (as needed)
• Consider updating Python bindings (if the library has them)
• codecheck passed (See contributing)
• All tests passed (See test coverage)
• While waiting for a review on your PR, please help review another open pull request to support the maintainers

Note to maintainers: Remember to use Squash-Merge and edit the commit message to match the pull request summary while retaining Signed-off-by messages.

[arjo129]

I tried this branch and introduced a segfault, however the stack traces are not being printed. I'll go through and check more thoroughly.

[arjo129]

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

[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.

[arjo129]

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

[arjo129]

Sadly, this won't work for the tests, perhaps Backward::Object? Or linking tests with whole-archive options enabled.

[j-rivero]

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

[arjo129]

Thanks! LGTM! There was a minor style issue with regards to spacing, I've pushed a commit that fixes it.

[j-rivero]

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.

[j-rivero]

@osrf-jenkins run tests

[scpeters]

this reverted #2838, and @j-rivero predicted this fragility in #2838 (comment)

for now the debbuild is unstable due to these installed files since BackwardConfig.cmake is not included in any package install rules

• https://build.osrfoundation.org/job/gz-sim10-debbuilder/247/

[azeey]

@j-rivero I think we want to avoid installing backward.hpp. Currently, libgz-sim10-dev wants to install it in /usr/include which conflicts with libbackward-cpp-dev.

$ dpkg -L libgz-sim10-dev | rg backward
/usr/include/backward.hpp

[j-rivero]

@j-rivero I think we want to avoid installing backward.hpp. Currently, libgz-sim10-dev wants to install it in /usr/include which conflicts with libbackward-cpp-dev.

There are different workarounds for this including the modification of the files imported that we did in #2838 or the customization of our deb metadata. The first is fragile as time has demonstrated, the second is only affecting .deb installations and leaving other packagers/builds with the problem.

There is an open PR with changes close to what Steve was proposing bombela/backward-cpp#338. I'm include to resurrect the code changes and document it a bit better for gaining visibility on the changes. I'll open a PR.