void main() { Test a; // line 3 /* place anything here */ import std.stdio; int x = 12; int y = 13; int z = x + y; writeln(z); /* to here */ a.blow(); // line 13 } struct Test { void blow() { throw new Exception(""); // line 20 } } ---- Stack trace: object.Exception@main.d(20) ---------------- main.d:20 void main.Test.blow() [0x4351ab] main.d:3 _Dmain [0x43511e] ??:? _D2rt6dmain211_d_run_mainUiPPaPUAAaZiZ6runAllMFZ9__lambda1MFZv [0x43691e] ??:? void rt.dmain2._d_run_main(int, char**, extern (C) int function(char[][])*).tryExec(scope void delegate()) [0x436874] ??:? void rt.dmain2._d_run_main(int, char**, extern (C) int function(char[][])*).runAll() [0x4368da] ??:? void rt.dmain2._d_run_main(int, char**, extern (C) int function(char[][])*).tryExec(scope void delegate()) [0x436874] ??:? _d_run_main [0x4367d1] ??:? main [0x4358cf] ??:? __libc_start_main [0x611e3a3f] ---- The stack trace at 0x43511e should point at line 13 instead of line 3. Output from addr2line matches file/line for each address. So the bug should be in the dwarf data itself. ---- Output from `readelf --debug-dump=decodedline main`: CU: main.d: File name Line number Starting address ./main.d:[++] main.d 1 0x4350e8 main.d 3 0x4350f1 main.d 7 0x4350f8 main.d 8 0x435100 main.d 9 0x435108 main.d 7 0x435108 main.d 8 0x435108 main.d 10 0x43510e main.d 9 0x43510e main.d 13 0x435116 main.d 3 0x435116 main.d 14 0x435121 ./main.d:[++] main.d 18 0x435128 main.d 20 0x435169 main.d 21 0x4351ac ---- Output from `readelf --debug-dump=rawline main`: Line Number Statements: [0x000001c8] Extended opcode 2: set Address to 0x4350e8 [0x000001d3] Set File Name to entry 1 in the File Name Table [0x000001d5] Special opcode 5: advance Address by 0 to 0x4350e8 and Line by 0 to 1 [0x000001d6] Special opcode 133: advance Address by 9 to 0x4350f1 and Line by 2 to 3 [0x000001d7] Special opcode 107: advance Address by 7 to 0x4350f8 and Line by 4 to 7 [0x000001d8] Special opcode 118: advance Address by 8 to 0x435100 and Line by 1 to 8 [0x000001d9] Special opcode 118: advance Address by 8 to 0x435108 and Line by 1 to 9 [0x000001da] Special opcode 3: advance Address by 0 to 0x435108 and Line by -2 to 7 [0x000001db] Special opcode 6: advance Address by 0 to 0x435108 and Line by 1 to 8 [0x000001dc] Special opcode 91: advance Address by 6 to 0x43510e and Line by 2 to 10 [0x000001dd] Special opcode 4: advance Address by 0 to 0x43510e and Line by -1 to 9 [0x000001de] Special opcode 121: advance Address by 8 to 0x435116 and Line by 4 to 13 [0x000001df] Advance Line by -10 to 3 [0x000001e1] Copy [0x000001e2] Advance Line by 11 to 14 [0x000001e4] Advance PC by 11 to 0x435121 [0x000001e6] Copy [0x000001e7] Advance PC by 7 to 0x435128 [0x000001e9] Extended opcode 1: End of Sequence [0x000001ec] Extended opcode 2: set Address to 0x435128 [0x000001f7] Set File Name to entry 1 in the File Name Table [0x000001f9] Advance Line by 17 to 18 [0x000001fb] Copy [0x000001fc] Advance Line by 2 to 20 [0x000001fe] Advance PC by 65 to 0x435169 [0x00000200] Copy [0x00000201] Advance Line by 1 to 21 [0x00000203] Advance PC by 67 to 0x4351ac [0x00000205] Copy [0x00000206] Advance PC by 4 to 0x4351b0 [0x00000208] Extended opcode 1: End of Sequence
We have that since ages, during a debug session when accessing a variable the address jumps to the declaration of that variable. I guess there is even an existing but report for that.
I fear that, as now file/line info show in backtraces, these bugs will be more annoying and prevalent.
I am sure there is a lot of other cases too.
I was going to write a bug report regarding a similar issue I had and found this bug. Any update on that? My observations: * wrong line numbers (off by 1 or more) are shown when debugging with lldb and compiling with dmd -g * ldc doesn't have this issue
Seems to be fixed for a while, but I couldn't find the commit which fixed it.