Hey folks, this is kind of niche, but a lot of you have more Windows development experience than I do and I'm at a loss as to what to try next.
Some of you know that I'm having a hard time getting useful panic stacktraces out of Rust, Sentry, and possibly Windows. I include that last bit because it's possible this is OS-specific, and filtering Sentry reports by OS isn't something I've figured out how to do yet. All my filenames/line numbers are <unknown> in any stacktraces I receive over Sentry, despite them seeming to be intact from Linux users running on consoles and copying logs from the terminal. Before I throw in the towel, integrate a file logger, and deal with the eternal stream of people who will report crashes and not send it along, I'd like to make one last stab at debugging this. Here's what I've done so far:
My Cargo.toml includes:
[profile.release]
debug = true
codegen-units = 1
lto = true
I created a small sample project, built in release mode. I started with nothing but a panic. I added my game engine. I initialized it. I changed the project to build as a Rust library, and then called into that library from a second binary. I stripped my release profile down to `debug = true` in case LTO and other optimizations were messing up stacktraces. Each and every time I rebuilt in release mode, caused the panic, and saw it in Sentry. Each time it included filenames/line numbers as it should.
I added code to System Fault to trigger a panic after 30 seconds. I ran it first via `cargo run --release`. Next I built a release package like those I distribute, unarchived it, and ran it from terminal. Then I opened the directory in Explorer and clicked on the executable in case something about the terminal session was making it work. Each time, filenames/line numbers showed up in the crash.
The only thing that's common here is my system. So there are two possibilities:
There's some path the code takes that changes whether line numbers make it into stacktraces. I can't think of what this could possibly be--I'm including it to cover all possible scenarios.
Something about how the executable is packed means it will always register correct filenames/line numbers on my system, but whatever tables are included aren't valid on other systems for some reason. Again, can't think of what might cause this, particularly as I ran identical builds. I'm also statically linking the MSVC runtime now, though these panics didn't report correctly even before I took that step.
Any ideas? Historically I've used Sentry in something like a Docker container, where I've got a whole lot of control over the runtime environment. Also, all the crashes appear to be in my engine. They're not buried in some DLL that might differ across Windows releases. Even if I were to fix any engine crashes, I'd need their coordinates so I could trace down what's wrong.
I've opened an issue on the Sentry Rust bindings, so hopefully someone there could help. But I thought I'd try here in case there's some obvious Windows-specific thing I'm not doing. It'd be great if my extensive attempts to trigger some of these actually worked, but I guess that'd make my life too easy. and who the hell expects to have an easy life anymore?
Thanks for any pointers.