Skip to content
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

Figure out pstack and Rust strip = "symbols" interaction #147

Open
sunshowers opened this issue Mar 28, 2024 · 5 comments
Open

Figure out pstack and Rust strip = "symbols" interaction #147

sunshowers opened this issue Mar 28, 2024 · 5 comments

Comments

@sunshowers
Copy link
Contributor

(writing up a quick summary so I don't forget about this)

@jclulow reported to me that a hung nextest process didn't show its symbols in pstack. It turned out that was because the build process we were using within nextest was stripping all symbols.

I tried switching to strip = "debuginfo" but that didn't seem to help. The only thing that caused stacks to show up in pstack was strip = "none".

In nextest-rs/nextest@d4f982b#commitcomment-140289873, Taiki believes that this is a bug (there was apparently a similar bug in MSVC as well.) I tried setting up a small project to investigate:

https://github.com/sunshowers/pstack-test

but found that even with the strip-symbols profile (which activates strip = "symbols"), pstack could show function symbols. Not quite clear why that would be happening though!

sunshowers referenced this issue in nextest-rs/nextest Mar 28, 2024
Restore behavior changed in 4e259a7, because
it turns out that `strip = "debuginfo"` still strips too much.

This was observed with the cargo-nextest 0.9.68-rc.1 binary on illumos, where
`pstack` showed lots of ??? marks.

Part of #1345.
@taiki-e
Copy link

taiki-e commented Mar 28, 2024

but found that even with the strip-symbols profile (which activates strip = "symbols"), pstack could show function symbols. Not quite clear why that would be happening though!

Does this mean there is a problem only with strip=debuginfo?

Also, is this a problem that only occurs with cross-compilation?

If both are true, since only strip=debuginfo use /usr/bin/strip, that would be consistent with my guess in nextest-rs/nextest@d4f982b#commitcomment-140325483 that non-illumos host's /usr/bin/strip are causing some problems.

@sunshowers
Copy link
Contributor Author

Does this mean there is a problem only with strip=debuginfo?

Ah no, I mean that no matter what I set strip to, I couldn't reproduce the results.

I do think this is likely a cross-compilation issue as you pointed out -- I was doing my builds natively on illumos but the CI that runs strip was doing a cross-compile from Linux.

@sunshowers
Copy link
Contributor Author

@taiki-e -- so what can we do here? Is this something where rustc can help, or maybe cross?

@taiki-e
Copy link

taiki-e commented Mar 29, 2024

For now, I think it makes sense to wait for discussion at the next compiler-team meeting (rust-lang/rust#123151 (comment)).

If the decision is made to use llvm-strip, the fix will likely be backported to stable (as it also affects macOS, which is tier 1 target).

@workingjubilee
Copy link

Huh, reading this: https://illumos.org/books/dev/debugging.html

Let's take a look now at pstack. As long as sufficient information for debugging is present in a binary, pstack can tell you what's going on. pstack doesn't rely on DWARF, it simply needs to have access to the symbol table and a frame pointer. If it's software in illumos, you can rest assured that it comes this way by default.

pstack doesn't rely on DWARF? oh dear... I think our backtrace testing infra assumes that you're using the DWARF-centric unwinding and symbolication strategy if you're a Unix...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants