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

Recent nightly shows no info in backtraces #61416

Closed
estebank opened this issue Jun 1, 2019 · 16 comments · Fixed by #61502
Closed

Recent nightly shows no info in backtraces #61416

estebank opened this issue Jun 1, 2019 · 16 comments · Fixed by #61502
Assignees
Labels
A-debuginfo Area: Debugging information in compiled programs (DWARF, PDB, etc.) O-macos Operating system: macOS O-windows Operating system: Windows regression-from-stable-to-nightly Performance or correctness regression from stable to nightly. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@estebank
Copy link
Contributor

estebank commented Jun 1, 2019

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>:

$ RUST_BACKTRACE=full rustc +devel file.rs -Ztreat-err-as-bug
error[E0573]: expected type, found function `foo`
  --> file.rs:10:17
   |
10 |     let _ = S::<foo()> { x: [u8; foo()] };
   |                 ^^^^^ not a type

thread 'rustc' panicked at 'aborting due to `-Z treat-err-as-bug=1`', src/librustc_errors/lib.rs:534:13
stack backtrace:
   0:        0x1115d3c84 - <unknown>
   1:        0x1115d1036 - <unknown>
   2:        0x1115d0dba - <unknown>
   3:        0x10f251322 - <unknown>
   4:        0x1115d1731 - <unknown>
   5:        0x11126f3b4 - <unknown>
   6:        0x11128a9b6 - <unknown>
   7:        0x111299fdc - <unknown>
   8:        0x10bbfcae9 - <unknown>
   9:        0x10b3e579d - <unknown>
  10:        0x10b333c10 - <unknown>
  11:        0x10b45b5b5 - <unknown>
  12:        0x10b43abe6 - <unknown>
  13:        0x10b330794 - <unknown>
  14:        0x10b39064d - <unknown>
  15:        0x10b38fa48 - <unknown>
  16:        0x10b391032 - <unknown>
  17:        0x10b4121db - <unknown>
  18:        0x10b0fa37e - <unknown>
  19:        0x10b178086 - <unknown>
  20:        0x10b167175 - <unknown>
  21:        0x10b175484 - <unknown>
  22:        0x10b11ce69 - <unknown>
  23:        0x1115f2cce - <unknown>
  24:        0x10b166408 - <unknown>
  25:        0x10b0d516b - <unknown>
  26:        0x1115b958d - <unknown>
  27:        0x1115f234d - <unknown>
  28:        0x1115e7bc8 - <unknown>
  29:     0x7fff784492ea - <unknown>
  30:     0x7fff7844c248 - <unknown>
query stack during panic:
end of query stack

Sadly I don't have a more specific repro case, but I can consistently reproduce locally. Older distributed nightlies do not present this behavior.

@estebank estebank added O-macos Operating system: macOS A-debuginfo Area: Debugging information in compiled programs (DWARF, PDB, etc.) T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Jun 1, 2019
@varkor
Copy link
Member

varkor commented Jun 1, 2019

This happens consistently for me as well (also macOS).

@Manishearth
Copy link
Member

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)

@varkor
Copy link
Member

varkor commented Jun 1, 2019

We should have tests for backtraces, so they don't regress again in the future.

@estebank
Copy link
Contributor Author

estebank commented Jun 1, 2019

@Manishearth this is certainly happening on master, and it's been happening for a while, but I assumed it was my env.

@estebank
Copy link
Contributor Author

estebank commented Jun 1, 2019

It just occurred to me that this might be related to the new symbol mangling #57967 (although I doubt it).

@wesleywiser
Copy link
Member

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 config.toml:

# 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

@eddyb
Copy link
Member

eddyb commented Jun 3, 2019

#57967 has absolutely no changes if you don't use the -Z flag, so it's not from there.

@ehuss
Copy link
Contributor

ehuss commented Jun 3, 2019

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 backtrace, but it didn't help.

@alexcrichton
Copy link
Member

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

@alexcrichton
Copy link
Member

Ok I believe I've found the issue for OSX, but if other platforms are still an issue that would be good to know

@ehuss
Copy link
Contributor

ehuss commented Jun 3, 2019

I've only experienced this with rustc itself on OSX. Things it builds seem ok, and linux/windows seem to be ok.

@Manishearth
Copy link
Member

No, it's still happening on Linux as of yesterday (I can try again today). I also assumed it was my env.

@Manishearth
Copy link
Member

I think the Linux issue is separate since it's been happening much longer than the OSX one

@udoprog
Copy link
Contributor

udoprog commented Jun 3, 2019

Hey, this seems to an issue on nightly for Windows (msvc) as well:

This uses backtrace 0.3.26 via failure:

2019-06-03T19:14:21.538096500+02:00 ERROR setmod_bot - stack backtrace:
   0: <no info> (0x7ff6faa66562)
      /* snip */
 107: <no info> (0x7ff6faaaf3a6)
 108: BaseThreadInitThunk (0x7ff8c1f97974)
 109: RtlUserThreadStart (0x7ff8c4c1a271)

alexcrichton added a commit to rust-lang/backtrace-rs that referenced this issue Jun 3, 2019
@alexcrichton
Copy link
Member

@udoprog if that's only using the backtrace crate and not using libstd, can you open an issue on the repository?

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 backtrace crate rather than libstd that's even better!

@udoprog
Copy link
Contributor

udoprog commented Jun 3, 2019

Done: rust-lang/backtrace-rs#197

@estebank estebank added regression-from-stable-to-nightly Performance or correctness regression from stable to nightly. O-macos Operating system: macOS O-windows Operating system: Windows and removed O-macos Operating system: macOS labels Jun 4, 2019
alexcrichton added a commit to alexcrichton/rust that referenced this issue Jun 5, 2019
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
bors added a commit that referenced this issue Jun 5, 2019
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
bors added a commit that referenced this issue Jun 5, 2019
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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-debuginfo Area: Debugging information in compiled programs (DWARF, PDB, etc.) O-macos Operating system: macOS O-windows Operating system: Windows regression-from-stable-to-nightly Performance or correctness regression from stable to nightly. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

8 participants