Troubleshooting

If you need help solving issues with the Sentry Rust SDK, you can read the edge cases documented below.

As a first step to debug any issue with the SDK, you should perform initialization with debug: true in your ClientOptions struct passed to sentry::init. This will make the SDK log additional debug information on stderr.

Read below to find a list of common problems and how to solve them.

Panic on SDK initialization

The SDK has been reported to panic on initialization when using the debug-images feature on machines with specific versions of the Linux kernel due to an issue with one of its dependencies.

Please open a GitHub issue with your OS and kernel version if you're affected by this.

Duplicated stack frames

There's an issue where stack frames can appear to be duplicated in Sentry with respect to the real stack trace. As there's a currently a hard limit of 200 frames in ingestion, this can cause errors to be missing stack frames when the limit is exceeded. This happens when the stack trace is already symbolicated on the client (due to debug information being present at runtime) but gets resymbolicated on the server.

There are two alternative ways to address this problem:

  • keep debug information in the binary, but disable the debug-images feature of the sentry crate;
  • strip debug information from the binary, and upload debug files separately.
'This frame has an unknown problem and can not be symbolicated' error in the UI for application stack frames

This can happen when your executable doesn't have a build ID, and therefore stack frames cannot be associated with any debug files by the Sentry backend.

To ensure cargo embeds a build ID in your binary, set the following environment variable when building: RUSTFLAGS="-Clink-args=-Wl,--build-id".

Was this helpful?
Help improve this content
Our documentation is open source and available on GitHub. Your contributions are welcome, whether fixing a typo (drat!) or suggesting an update ("yeah, this would be better").