Bug 18068 – No file names and line numbers in stack trace

Status
RESOLVED
Resolution
FIXED
Severity
regression
Priority
P1
Component
dmd
Product
D
Version
D2
Platform
x86_64
OS
Linux
Creation time
2017-12-12T12:33:10Z
Last change time
2018-08-24T07:43:24Z
Assigned to
No Owner
Creator
Mike Franklin
See also
https://issues.dlang.org/show_bug.cgi?id=19016

Comments

Comment #0 by slavo5150 — 2017-12-12T12:33:10Z
--- void main() { assert(false); } --- [email protected](3): Assertion failure ---------------- ??:? _d_assertp [0x5339d26d] ??:? _Dmain [0x5339d1a4] Notice the ??:?. No file names or line numbers See also http://forum.dlang.org/post/[email protected]
Comment #1 by jack — 2017-12-12T14:23:16Z
This is a regression.
Comment #2 by doob — 2017-12-12T15:46:40Z
Make sure that tests are added this time as well.
Comment #3 by greensunny12 — 2017-12-13T05:19:07Z
FWIW there's a test case: https://github.com/dlang/dmd/blob/master/test/runnable/test17559.d It's just never run with `-fPIC`.
Comment #4 by greensunny12 — 2017-12-13T09:13:06Z
And the DRuntime testcase doesn't work either: make -f posix.mak test/exceptions/.run BUILD=debug
Comment #5 by greensunny12 — 2018-01-15T10:15:24Z
test/runnable/test17559.d in the DMD testsuite fails too.
Comment #6 by slavo5150 — 2018-01-31T10:01:53Z
I've narrowed down the problem to this `if` statement: https://github.com/dlang/druntime/blob/bff4d4bd3c4a320f4743a2ac5c5c0bd7df5d593c/src/rt/backtrace/dwarf.d#L201 That is `loc.address` and `address` are never equal. `loc.address` is populated from here (https://github.com/dlang/druntime/blob/4992bfa44c6bdfbafed078533869095b2b09ca78/src/core/runtime.d#L757) and eventually passed to `traceHandlerOpApplyImpl` here (https://github.com/dlang/druntime/blob/4992bfa44c6bdfbafed078533869095b2b09ca78/src/core/runtime.d#L807) I printed out the two addresses in the encasing `foreach` loop, and this is as sample of what I see. `loc.address` `address` 0x4627b123 0x380cc 0x4627b9cb 0x380cc 0x4627b85b 0x380cc 0x4627b93a 0x380cc 0x4627b85b 0x380cc 0x4627b7c6 0x380cc 0x4627b531 0x380cc 0x8b4e3f49 0x380cc 0x4627b123 0x380d8 0x4627b9cb 0x380d8 0x4627b85b 0x380d8 0x4627b93a 0x380d8 0x4627b85b 0x380d8 0x4627b7c6 0x380d8 0x4627b531 0x380d8 0x8b4e3f49 0x380d8 0x4627b123 0x3814e 0x4627b9cb 0x3814e 0x4627b85b 0x3814e 0x4627b93a 0x3814e 0x4627b85b 0x3814e 0x4627b7c6 0x3814e 0x4627b531 0x3814e 0x8b4e3f49 0x3814e 0x4627b123 0x38170 0x4627b9cb 0x38170 0x4627b85b 0x38170 The values for `address` are consistent with what I see from readelf: $ readelf --debug-dump=decodedline main Decoded dump of debug contents of section .debug_line: CU: main.d: File name Line number Starting address ./main.d:[++] main.d 3 0x30cbc main.d 5 0x30cc8 main.d 9 0x30cd8 main.d 13 0x30d4e main.d 15 0x30d6d At this point, I might have to give up on this. I hope the information above will help someone.
Comment #7 by doob — 2018-01-31T10:29:17Z
(In reply to Mike Franklin from comment #6) > I've narrowed down the problem to this `if` statement: > https://github.com/dlang/druntime/blob/ > bff4d4bd3c4a320f4743a2ac5c5c0bd7df5d593c/src/rt/backtrace/dwarf.d#L201 > > That is `loc.address` and `address` are never equal. `loc.address` is > populated from here > (https://github.com/dlang/druntime/blob/ > 4992bfa44c6bdfbafed078533869095b2b09ca78/src/core/runtime.d#L757) and > eventually passed to `traceHandlerOpApplyImpl` here > (https://github.com/dlang/druntime/blob/ > 4992bfa44c6bdfbafed078533869095b2b09ca78/src/core/runtime.d#L807) Since these two files in druntime haven't changed much recently, I'm guessing it's something that's changed in DMD.
Comment #8 by arne.ludwig — 2018-04-19T10:21:06Z
This problem doesn't seem to affect all Linux systems. So, please report your Distribution and Kernel (type `uname -r` in shell). Works: Linux *** 4.4.0-119-generic #143-Ubuntu SMP Mon Apr 2 16:08:24 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux Fails: Linux *** 4.15.15-1-ARCH #1 SMP PREEMPT Sat Mar 31 23:59:25 UTC 2018 x86_64 GNU/Linux
Comment #9 by greensunny12 — 2018-04-19T10:29:01Z
FWIW my current guess is that its related to a "recent" change in glibc. This could also be related: https://github.com/dlang/druntime/pull/2151 > The latter is how I stumbled on this. LLVM 6.0 led to DWARF v4 debuginfos, rt.backtrace.dwarf doesn't support that version, so no file/line infos => "??:? \0" + exception
Comment #10 by dmitry.olsh — 2018-05-17T07:23:45Z
*** Issue 3933 has been marked as a duplicate of this issue. ***
Comment #11 by github-bugzilla — 2018-06-28T12:50:18Z
Commits pushed to master at https://github.com/dlang/druntime https://github.com/dlang/druntime/commit/5f75d73ba89b7ad5da268dcb0791c4b264c02d5f Fix Issue 18068 - No file names and line numbers in stack trace https://github.com/dlang/druntime/commit/08edc735ae2cdef68fe1812ccc8666816a6e8578 Merge pull request #2230 from JinShil/debug_line-aslr Fix Issue 18068 - No file names and line numbers in stack trace
Comment #12 by slavo5150 — 2018-08-17T11:49:52Z
Comment #13 by github-bugzilla — 2018-08-24T07:43:23Z
Commits pushed to master at https://github.com/dlang/druntime https://github.com/dlang/druntime/commit/4ffb551929eae45bb80fc14f8a12aa6348f65fc0 Fix Issue 18068 - No file names and line numbers in stack trace - Again https://github.com/dlang/druntime/commit/45f340f6f89134b2dce95381d129a6343a300939 Merge pull request #2278 from JinShil/fix_18068_again Fix Issue 18068 - No file names and line numbers in stack trace - Again