Debug Identifiers
Learn about build tooling requirements that allow Sentry to uniquely identify debug information files across builds.
Each debug information file specifies a unique identifier. Crash reports declare these identifiers to allow debuggers and crash reporting systems to resolve the correct files. Sentry distinguishes two kinds of identifiers:
Code Identifier: The unique identifier of the executable or dynamic library -- the code file. The contents of this identifier are platform-dependent: Mach-O files use a UUID, ELF files a SHA hash, PE files use a concatenation of certain header attributes. For WebAssembly we use an embedded UUID in the
build_id
section of the file.Debug Identifier: The unique identifier of the debug companion file. In contrast to the code identifier, Sentry enforces the same structure on all platforms. On Windows, this is the actual unique id of the PDB file; on all other platforms this is a lossy transformation of the code identifier.
When uploading debug information files to Sentry, the CLI and server will always compute a Debug Identifier for each uploaded file. This identifier is associated with executables and libraries as well as debug companions to ensure that they can be uniquely located via one common mechanism.
Debug information does not have to be associated with releases. The unique debug identifier ensures that Sentry can choose the right files for every crash report. However, it is still recommended to configure releases in the client to benefit from other features.
For native events, the issue details page displays a list of Loaded Images. This list contains the executable and all loaded dynamic libraries including their debug identifiers. You can copy this identifier and search for the exact files that match it in the Debug Files settings screen.
sentry-cli
can help to print properties of debug information files like their debug identifier. See Checking Debug Information Files for more information.
WebAssembly supports build IDs as a custom section.
LLVM
(and with it, the corresponding emscripten
toolchain) supports this since version 17.
Our wasm-split
tool can also be used to add a build ID if your toolchain doesn't support this yet. It also allows you to split and extract debug information from your *.wasm
file.
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").