regression: `panic!` and RUST_BACKTRACE=1 Show Wrong & Non-Informative Function Names when Unwinding

[DK26]

As I'm learning the language from a book ("The Complete Rust Programming Reference Guide" p. 229-230), and was executing the panic! macro in a multi-thread environment, I've noticed the unwinding from the book is different from the one I've got where the one I've got is not informative or helpful, and seems wrong where the one in book seems to be OK.

Code

I tried this code:

// panic_unwinding.rs

use std::thread;

fn alice() -> thread::JoinHandle<()> {
    thread::spawn(move || {
        bob();
    })
}

fn bob() {
    malice();
}

fn malice() {
    panic!("malice is panicking!");
}

fn main() {

    let child = alice();
    let _ = child.join();

    bob();
    println!("This is unreachable code");
    
}

I expected the backtrace to include the function names as they were called, all the way from the entry point of the threads.

Instead, all functions were named the same:
(env: RUST_BACKTRACE=1)

thread '<unnamed>' panicked at 'malice is panicking!', .\panic_unwinding.rs:16:5
stack backtrace:
   0: std::panicking::begin_panic
   1: panic_unwinding::alice::{{closure}}
   2: panic_unwinding::alice::{{closure}}
   3: panic_unwinding::alice::{{closure}}
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
thread 'main' panicked at 'malice is panicking!', .\panic_unwinding.rs:16:5
stack backtrace:
   0: std::panicking::begin_panic
   1: panic_unwinding::alice::{{closure}}
   2: panic_unwinding::alice::{{closure}}
   3: panic_unwinding::alice::{{closure}}
   4: core::ops::function::FnOnce::call_once
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

Version it worked on

I don't know from when is the regression. The book is using an old version of Rust: 1.32.0

Version with regression

I use the most current version: Rust 1.47.0

rustc --version --verbose:

rustc 1.47.0 (18bf6b4f0 2020-10-07)
binary: rustc
commit-hash: 18bf6b4f01a6feaf7259ba7cdae58031af1b7b39
commit-date: 2020-10-07
host: x86_64-pc-windows-msvc
release: 1.47.0
LLVM version: 11.0

Simply testing the example code as provided I find,

thread '<unnamed>' panicked at 'malice is panicking', src/main.rs:14:5
stack backtrace:
   0: std::panicking::begin_panic
             at /rustc/18bf6b4f01a6feaf7259ba7cdae58031af1b7b39/library/std/src/panicking.rs:497
   1: test_crate::malice
             at ./src/main.rs:14
   2: test_crate::bob
             at ./src/main.rs:10
   3: test_crate::alice::{{closure}}
             at ./src/main.rs:5
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
thread 'main' panicked at 'malice is panicking', src/main.rs:14:5
stack backtrace:
   0: std::panicking::begin_panic
             at /rustc/18bf6b4f01a6feaf7259ba7cdae58031af1b7b39/library/std/src/panicking.rs:497
   1: test_crate::malice
             at ./src/main.rs:14
   2: test_crate::bob
             at ./src/main.rs:10
   3: test_crate::main
             at ./src/main.rs:21
   4: core::ops::function::FnOnce::call_once
             at /rustc/18bf6b4f01a6feaf7259ba7cdae58031af1b7b39/library/core/src/ops/function.rs:227
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

, under,

rustc 1.47.0 (18bf6b4f0 2020-10-07)
binary: rustc
commit-hash: 18bf6b4f01a6feaf7259ba7cdae58031af1b7b39
commit-date: 2020-10-07
host: x86_64-unknown-linux-gnu
release: 1.47.0
LLVM version: 11.0

, so this might be restricted to O-windows or is that already known?

[apiraino]

Bisected to nightly-2020-08-09

found 13 bors merge commits in the specified range
  commit[0] 2020-08-07UTC: Auto merge of #75255 - davidtwco:polymorphisation-symbol-mangling-v0-upvar-closures, r=lcnr
  commit[1] 2020-08-07UTC: Auto merge of #75071 - ssomers:btree_cleanup_5, r=Mark-Simulacrum
  commit[2] 2020-08-08UTC: Auto merge of #75048 - eggyal:force-no-tco-start-backtrace-frame, r=Mark-Simulacrum
  commit[3] 2020-08-08UTC: Auto merge of #74877 - lcnr:min_const_generics, r=oli-obk
  commit[4] 2020-08-08UTC: Auto merge of #75276 - JohnTitor:rollup-rz4hs0w, r=JohnTitor
  commit[5] 2020-08-08UTC: Auto merge of #74932 - nnethercote:rm-ast-session-globals, r=petrochenkov
  commit[6] 2020-08-08UTC: Auto merge of #75257 - ssomers:btree_74762_again, r=Mark-Simulacrum
  commit[7] 2020-08-08UTC: Auto merge of #75282 - RalfJung:miri-black-box, r=oli-obk
  commit[8] 2020-08-08UTC: Auto merge of #74289 - lzutao:unroll, r=LukasKalbertodt
  commit[9] 2020-08-08UTC: Auto merge of #74533 - nikic:issue-74425, r=eddyb
  commit[10] 2020-08-08UTC: Auto merge of #75260 - davidtwco:polymorphization-promoted-substs, r=lcnr
  commit[11] 2020-08-08UTC: Auto merge of #75163 - canova:map_into_keys_values, r=dtolnay
  commit[12] 2020-08-08UTC: Auto merge of #75271 - cuviper:array-iter, r=LukasKalbertodt
ERROR: no commits between 09f4c9f5082f78b0adcee83d3ab4337e000cd28e and 
    ceedf1d5febd65b012b8bcd513d70a0a6a091210 within last 167 days

(if I've done correctly), bisected with script:

$ RUST_SRC_REPO=~/rust cargo-bisect-rustc --preserve --start=2020-06-01 --end=2020-10-08 --script=./test.sh

$ cat ./test.sh
#!/bin/sh
RUST_BACKTRACE=1 cargo run 2>&1 | grep __libc_start_main

[apiraino]

Assigning priority as discussed as part of the Prioritization Working Group procedure and removing I-prioritize.

@rustbot label -I-prioritize +P-medium

[eggyal]

I think #75048 was the likely culprit.

[eggyal]

Is the backtrace correctly described with RUST_BACKTRACE=full?

[apiraino]

Is the backtrace correctly described with RUST_BACKTRACE=full?

@eggyal In my local test with RUST_BACKTRACE=full seems to print the full stacktrace as expected.
(I don't have access to the reference mentioned by the issue reporter so I cannot compare)

[m-ou-se]

Has this issue been fixed?