Rust: Recent nightly shows no info in backtraces

[estebank]

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.

[varkor]

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

[Manishearth]

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]

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

[estebank]

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

[estebank]

It just occurred to me that this _might_ be related to the new symbol mangling https://github.com/rust-lang/rust/pull/57967 (although I doubt it).

[wesleywiser]

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]

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

[ehuss]

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]

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]

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]

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

[Manishearth]

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

[Manishearth]

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

[udoprog]

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]

@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 https://github.com/rust-lang/backtrace-rs/pull/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]

Done: rust-lang/backtrace-rs#197