The debug information file used was broken

[glennra]

Environment

SaaS (https://sentry.io/)

Steps to Reproduce

We are building a Qt desktop app on Windows with the bundled MinGW compiler (Qt 6.5, MinGW 11.2.0).
Debug symbols for a Release build are produced by adding the -g compiler flag.
A pdb is created from the exe using cv2pdb64 and the symbol file is created using dump_syms.

sentry-cli debug-files check <name>.pdb
sentry-cli debug-files check <name>.sym
both report usable: yes

These files are uploaded using sentry-cli debug-files upload ...

When a crash event is viewed the event log has an error banner that says "The debug information file used was broken".

A minimal example using the above procedure works correctly.

Expected Result

The specific error in the debug information file should be reported by sentry-cli debug-files check ... or by the sentry.io dashboard.

Actual Result

The issue view reports "The debug information file used was broken"

Product Area

Issues

Link

No response

DSN

https://5cadff627e90cffc30172f038d0676f3@o4504238250983424.ingest.sentry.io/4506300114796544

Version

No response

[getsantry]

Assigning to @getsentry/support for routing ⏲️

[glennra]

I have narrowed this down. The issue happens when a stripped executable crashes.

cv2pdb64 myapp.exe outputs myapp.pdb and a stripped version of 'myapp.exe'. It is this stripped exe that causes the issue.

If the exe is left unmodified by cv2pdb64:

cv2pdb64 myapp.exe myapp_stripped.exe. myapp.pdb

then for a crash in the unstripped executable sentry does not complain about the debug information file and the stack trace shows the correct file and line number.

Alternatively using a manually stripped exe:

strip myapp.exe

also causes the issue.

It is undesirable to use the unstripped exe because of it's large size (in my actual use case 9MB vs 226MB).

[Swatinem]

Can you provide a link to an event, or to your "debug files" project settings page?
With that I can have a closer look at the failing file and figure out whats going on.

Ideally the file would just be processed correctly, and there wouldn’t need to be a need to display more detailed information in the Sentry UI.
We usually log more detailed versions of these errors as well internally, I could possibly filter those based on the project-id in your DSN, but a link to an event would be preferable.

---

That being said, the mingw toolchain is frequently causing problems with unusable debug-info, and formats that we simply do not support (yet).

[glennra]

Broken one - event ID: f401c806f8fe442c507e223cd46f513e
Working one - event ID: e90c376e638a4ccf1cd8089296123bed

[loewenheim]

Sorry, we need more than just event IDs. Links to the events would be best. You can also email them to me at sebastian.zivota@sentry.io if you'd rather.

[loewenheim]

Thanks for sending me the links. I analyzed the pdb file that gets reported as broken with symbolic and with llvm-pdbutil.

The output of symcache_debug, a utility within symbolic:

❯ cargo run -p symcache_debug -- -d /path/to/file
thread 'main' panicked at examples/symcache_debug/src/main.rs:267:23:
called `Result::unwrap()` on an `Err` value: bad debug file

Caused by:
    0: invalid pdb file
    1: UnexpectedEof

With some printf debugging I found that the problem occurs when trying to read the functions in the pdb file.

The output of llvm-pdbutil:

❯ llvm-pdbutil dump -all /path/to/file
[… lots of information …]
                          Modules                           
============================================================
  Mod 0000 | `__Globals`: Unexpected error processing modules: PDB does not contain the requested image section header type

As far as I can tell there is no problem with the executable itself, it's the debug file that's broken.

[glennra]

Some further observations:
This is how the debug info files are generated:
cv2pdb64 myapp.exe myapp_cv.exe myapp.pdb
dump_syms myapp.pdb > myapp.sym

With a pdb file that has the same error as above in symcache_debug and llvm-pdbutil:
if the unstripped version of the app crashes then I can see the file and line no. of the crash;
if the stripped version of the app, produced by cv2pdb64, crashes then sometimes I see the file and line no., sometimes not.

[loewenheim]

@glennra is there anything left for us to do at the moment?

[glennra]

It turns out that some of the 3rd party libraries in sentry-native don't build with MinGW and have to be built with MSVC. This means that the path of least resistance is to build our whole project with MSVC and in that case this issue isn't relevant.

[loewenheim]

Closing this for now, please let us know if we can help you further.