-
Notifications
You must be signed in to change notification settings - Fork 12.7k
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
Recent nightly shows no info in backtraces #61416
Comments
This happens consistently for me as well (also macOS). |
I've been seeing this on Linux too, though it's been at least a week. (It also may have been fixed in a rustc newer than the one servo uses) |
We should have tests for backtraces, so they don't regress again in the future. |
@Manishearth this is certainly happening on master, and it's been happening for a while, but I assumed it was my env. |
It just occurred to me that this might be related to the new symbol mangling #57967 (although I doubt it). |
I've been experiencing this for about a week now (also on macOS). It definitely started prior to #57967 being merged. I also have the following in my # Debuginfo level for most of Rust code, corresponds to the `-C debuginfo=N` option of `rustc`.
# `0` - no debug info
# `1` - line tables only
# `2` - full debug info with variable and type information
# Can be overriden for specific subsets of Rust code (rustc, std or tools).
# Debuginfo for tests run with compiletest is not controlled by this option
# and needs to be enabled separately with `debuginfo-level-tests`.
debuginfo-level = 2
# Debuginfo level for the compiler.
debuginfo-level-rustc = 2
# Debuginfo level for the standard library.
debuginfo-level-std = 2
# Debuginfo level for the tools.
debuginfo-level-tools = 2
|
#57967 has absolutely no changes if you don't use the |
It's definitely #60852, I tried before and after. It works if you enable the "coresymbolication" feature, though that's obviously not an option for distribution. I tried the latest master of |
To confirm, is everyone only experiencing problems on OSX for rustc itself? Are there problems with other projects on OSX? @Manishearth can you please confirm or deny your experience from Linux? Throwing in a new platform here changes this quite a lot |
Ok I believe I've found the issue for OSX, but if other platforms are still an issue that would be good to know |
I've only experienced this with rustc itself on OSX. Things it builds seem ok, and linux/windows seem to be ok. |
No, it's still happening on Linux as of yesterday (I can try again today). I also assumed it was my env. |
I think the Linux issue is separate since it's been happening much longer than the OSX one |
Hey, this seems to an issue on nightly for Windows (msvc) as well: This uses backtrace
|
@udoprog if that's only using the The OSX issue should be fixed in rust-lang/backtrace-rs#196, which I'd like to finish testing and then I'll send an update to libstd. That could affect Linux as well but I doubt it, so if there are persisting Linux/Windows issues please feel free to let me know. If you can create an isolated problem which uses the |
Discovered in rust-lang#61416 an accidental regression in libstd's backtrace behavior is that it previously attempted to consult libbacktrace and would then fall back to `dladdr` if libbacktrace didn't report anything. The `backtrace` crate, however, did not do this, so that's now been fixed! Changes: rust-lang/backtrace-rs@0.3.25...0.3.27 Closes rust-lang#61416
std: Update dependency on `backtrace` Discovered in #61416 an accidental regression in libstd's backtrace behavior is that it previously attempted to consult libbacktrace and would then fall back to `dladdr` if libbacktrace didn't report anything. The `backtrace` crate, however, did not do this, so that's now been fixed! Changes: rust-lang/backtrace-rs@0.3.25...0.3.29 Closes #61416
std: Update dependency on `backtrace` Discovered in #61416 an accidental regression in libstd's backtrace behavior is that it previously attempted to consult libbacktrace and would then fall back to `dladdr` if libbacktrace didn't report anything. The `backtrace` crate, however, did not do this, so that's now been fixed! Changes: rust-lang/backtrace-rs@0.3.25...0.3.29 Closes #61416
Every since a recent nightly update, both distributed nightlies and locally built
rustc
produce backtraces where every level of the stack is represented only by their memory address and the label<unknown>
:Sadly I don't have a more specific repro case, but I can consistently reproduce locally. Older distributed nightlies do not present this behavior.
The text was updated successfully, but these errors were encountered: