-
Notifications
You must be signed in to change notification settings - Fork 34
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Consider adding Backward-cpp
for gz_build_tests
#442
Comments
This is a great idea. I had started working on generating core dumps using |
I think right now I am prototyping on a branch. There are several issues I'll need to figure out:
|
After some consideration. Rather than deal with the mess of vendoring accross different platforms, since this only affects our tests, and generally flakiness is usually observed in a few libraries, I'm proposing we "vendor" the library with our test suite (via static linking). This avoids the need for us to figure out which packages and dependencies are. |
Desired behavior
Backward-cpp is used by
gz-tools
already and makes the debugging experience in gazebo a lot smoother. However, when we build unit tests for gazebo-sim downstream, we do not end up linking it with our unit tests. Thus when we have segfaults on the build farm we often don't have stack traces that may allow us to reproduce or reason about the error.Alternatives considered
N/A
Implementation suggestion
The simplest way would be to link it in the
gz_build_tests
macro. Currently we have two versions of the library one ingz-launch
and one ingz-tools
perhaps we could find a way of exporting the target fromgz-tools
? TBH I have no idea what the right way would be.The text was updated successfully, but these errors were encountered: