Stream: t-compiler/help

Topic: no backtrace

blitzerr (Feb 24 2019 at 02:38, on Zulip):

In what cases do we not get the backtrace even after running with the variable set RUST_BACKTRACE=1 ?

blitzerr (Feb 24 2019 at 02:39, on Zulip):

I am compiling it with
rustc +nightly <my program>
and I get the output as
thread 'main' panicked at 'attempt to subtract with overflow', /rustc/aadbc459bd97a0325897e2ff94999efbec6a499c/src/libcore/ops/ note: Run with RUST_BACKTRACE=1 environment variable to display a backtrace.

pnkfelix (Feb 25 2019 at 11:33, on Zulip):

what platform is this? Linux?

blitzerr (Feb 28 2019 at 18:28, on Zulip):

@pnkfelix MacOs. I manged to get back stack trace but I don't get the line numbers.

blitzerr (Feb 28 2019 at 18:32, on Zulip):

I found this #46346 but this was closed.

oli (Mar 01 2019 at 06:14, on Zulip):

A backtrace can be useful even without line numbers. You should be able to get a backtrace with line numbers by building the compiler yourself (or maybe by using

blitzerr (Mar 08 2019 at 15:07, on Zulip):

@oli I have debuginfo-lines = true in the config.toml

oli (Mar 08 2019 at 15:53, on Zulip):

and you're still not getting line numbers? Can you still post the backtrace? Even without line numbers we might be able to figure out where the issue comes from

pnkfelix (Mar 11 2019 at 14:30, on Zulip):

@blitzerr I don't understand, you said you're running rustc +nightly ... ; that is not running your local build then, right?

blitzerr (Mar 11 2019 at 17:03, on Zulip):

@pnkfelix That is true. With nightly or with stage 1 compiler, I don't get line numbers with stack trace.

pnkfelix (Mar 11 2019 at 17:04, on Zulip):

For nightly I think that’s expected, since nightly is built without debuginfo

Esteban Küber (Jun 01 2019 at 00:58, on Zulip):

I'm having a very similar problem: I get backtraces, but every level of the stack is identified only with unknown and nothing else. I've tried with every knob in config.toml that could possibly be related. Last few nightlies also have the same behavior. Platform is also macos.

Esteban Küber (Jun 01 2019 at 01:03, on Zulip):

An example of the output:

$ RUST_BACKTRACE=full rustc +devel -Ztreat-err-as-bug
error: couldn't read No such file or directory (os error 2)

thread 'rustc' panicked at 'aborting due to `-Z treat-err-as-bug=1`', src/librustc_errors/
stack backtrace:
   0:        0x10cd72c84 - <unknown>
   1:        0x10cd70036 - <unknown>
   2:        0x10cd6fdba - <unknown>
   3:        0x10a982322 - <unknown>
   4:        0x10cd70731 - <unknown>
   5:        0x10c9d43b4 - <unknown>
   6:        0x10c9ef9b6 - <unknown>
   7:        0x10c9fefdc - <unknown>
   8:        0x10c17959f - <unknown>
   9:        0x10c177e9e - <unknown>
  10:        0x106c0f742 - <unknown>
  11:        0x106c0edfa - <unknown>
  12:        0x106b573b9 - <unknown>
  13:        0x106bb6280 - <unknown>
  14:        0x106c390bb - <unknown>
  15:        0x10691fe4b - <unknown>
  16:        0x10699e086 - <unknown>
  17:        0x10698d175 - <unknown>
  18:        0x10699b484 - <unknown>
  19:        0x106942e69 - <unknown>
  20:        0x10cd91cce - <unknown>
  21:        0x10698c408 - <unknown>
  22:        0x1068fb16b - <unknown>
  23:        0x10cd5858d - <unknown>
  24:        0x10cd9134d - <unknown>
  25:        0x10cd86bc8 - <unknown>
  26:     0x7fff784492ea - <unknown>
  27:     0x7fff7844c248 - <unknown>
query stack during panic:
end of query stack
davidtwco (Jun 01 2019 at 07:36, on Zulip):

@varkor reported similar in Discord and linked to #60852, @Esteban Küber

varkor (Jun 01 2019 at 09:55, on Zulip):

that was after I saw @Esteban Küber's issue :P

davidtwco (Jun 01 2019 at 09:56, on Zulip):

Ah, I just saw both messages this morning and though they could be related.

nagisa (Jun 01 2019 at 11:05, on Zulip):

The stack frame addresses look sane, so the unwinder probably just fails to figure out what lines/functions/files/etc the instruction pointers come from)

Last update: Sep 18 2020 at 20:30UTC