www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Backtraces on Linux 64-bit

reply "aldanor" <i.s.smirnov gmail.com> writes:
Hi all,

Does anybody know what's the current story with 64-bit Linux 
backtraces? I've seen a couple of posts here and on stackoverflow 
(like this 
http://stackoverflow.com/questions/10527901/d2-not-getting-any-backtrace-info), 
couldn't find any definitive answers for the 64-bit case.

./test(pure  safe immutable(char)[] 
std.exception.enforce!(immutable(char)[]).enforce(immutable(char)[], 
lazy const(char)[], immutable(char)[], ulong)+0x6a) [0x50a85e]
./test(_Dmain+0x17f) [0x4a188b]
./test(extern (C) int rt.dmain2._d_run_main(int, char**, extern 
(C) int function(char[][])*).void runMain()+0x18) [0x529740]
./test(extern (C) int rt.dmain2._d_run_main(int, char**, extern 
(C) int function(char[][])*).void tryExec(scope void 
delegate())+0x2a) [0x529272]
./test(extern (C) int rt.dmain2._d_run_main(int, char**, extern 
(C) int function(char[][])*).void runAll()+0x40) [0x529790]
./test(extern (C) int rt.dmain2._d_run_main(int, char**, extern 
(C) int function(char[][])*).void tryExec(scope void 
delegate())+0x2a) [0x529272]
./oracle(_d_run_main+0x1ae) [0x52922e]
./test(main+0x17) [0x52907b]
/lib64/libc.so.6(__libc_start_main+0xe6) [0x7f87dd21dc36]


Note: I have the -L--export-dynamic flag enabled in dmd.conf, but 
it doesn't seem to do much; I'm running dmd64 v2.063.2.
Oct 28 2013
next sibling parent reply Martin Nowak <code dawg.eu> writes:
On 10/28/2013 11:43 AM, aldanor wrote:
 ./test(pure  safe immutable(char)[]
 std.exception.enforce!(immutable(char)[]).enforce(immutable(char)[],
 lazy const(char)[], immutable(char)[], ulong)+0x6a) [0x50a85e]
 ./test(_Dmain+0x17f) [0x4a188b]
 ./test(extern (C) int rt.dmain2._d_run_main(int, char**, extern (C) int
 function(char[][])*).void runMain()+0x18) [0x529740]
 ./test(extern (C) int rt.dmain2._d_run_main(int, char**, extern (C) int
 function(char[][])*).void tryExec(scope void delegate())+0x2a) [0x529272]
 ./test(extern (C) int rt.dmain2._d_run_main(int, char**, extern (C) int
 function(char[][])*).void runAll()+0x40) [0x529790]
 ./test(extern (C) int rt.dmain2._d_run_main(int, char**, extern (C) int
 function(char[][])*).void tryExec(scope void delegate())+0x2a) [0x529272]
 ./oracle(_d_run_main+0x1ae) [0x52922e]
 ./test(main+0x17) [0x52907b]
 /lib64/libc.so.6(__libc_start_main+0xe6) [0x7f87dd21dc36]
Apparently you have a stacktrace so what exactly is the problem?
 Note: I have the -L--export-dynamic flag enabled in dmd.conf, but it
 doesn't seem to do much; I'm running dmd64 v2.063.2.
It's really annoying that we rely on --export-dynamic for backtraces. Exporting symbols from the executable can have unwanted side effects. But unless someone writes a backtrace handler that understands DWARF we're stuck.
Oct 30 2013
parent reply "Dicebot" <public dicebot.lv> writes:
On Wednesday, 30 October 2013 at 20:14:30 UTC, Martin Nowak wrote:
 Apparently you have a stacktrace so what exactly is the problem?
It had line numbers and file names some time ago. I have missed the moment when it became broken :(
Oct 30 2013
parent reply Martin Nowak <code dawg.eu> writes:
On 10/30/2013 09:37 PM, Dicebot wrote:
 It had line numbers and file names some time ago. I have missed the
 moment when it  became broken :(
There are line numbers on windows. The unix stuff relies on the dynamic symbol tables to find symbol names (that's why it needs --export-dynamic). To get line number information you need to process debug information.
Oct 31 2013
parent reply "Dicebot" <public dicebot.lv> writes:
On Thursday, 31 October 2013 at 19:00:42 UTC, Martin Nowak wrote:
 There are line numbers on windows. The unix stuff relies on the 
 dynamic symbol tables to find symbol names (that's why it needs 
 --export-dynamic). To get line number information you need to 
 process debug information.
It does not work now even with --export-dynamic on Linux, that is the whole point.
Oct 31 2013
parent reply Martin Nowak <code dawg.eu> writes:
On 10/31/2013 08:05 PM, Dicebot wrote:
 It does not work now even with --export-dynamic on Linux, that is the
 whole point.
It can't by design, there are no line numbers in dynamic symbol tables.
Nov 09 2013
parent reply Timothee Cour <thelastmammoth gmail.com> writes:
On Sat, Nov 9, 2013 at 12:45 PM, Martin Nowak <code dawg.eu> wrote:

 On 10/31/2013 08:05 PM, Dicebot wrote:

 It does not work now even with --export-dynamic on Linux, that is the
 whole point.
It can't by design, there are no line numbers in dynamic symbol tables.
And yet lldb *can* display line numbers so the info is there. * thread #1: tid = 0x324b, 0x000000000041636c test2 fun2 + 4 at test.d:7, stop reason = breakpoint 1.1 frame #0: 0x000000000041636c test2 fun2 + 4 at test_multi.d:7 frame #1: 0x0000000000416381 test2 _D5tests10test_multi4fun1FZv + 9 at test_multi.d:10
Nov 09 2013
parent reply "Martin Nowak" <code dawg.eu> writes:
On Saturday, 9 November 2013 at 23:39:45 UTC, Timothee Cour wrote:
 And yet lldb *can* display line numbers so the info is there.
Yes, in the debug info. Also look at deadalnix reply.
Nov 09 2013
parent reply "yazd" <yazan.dabain gmail.com> writes:
On Saturday, 9 November 2013 at 23:48:54 UTC, Martin Nowak wrote:
 On Saturday, 9 November 2013 at 23:39:45 UTC, Timothee Cour 
 wrote:
 And yet lldb *can* display line numbers so the info is there.
Yes, in the debug info. Also look at deadalnix reply.
I've implemented a simple thing using addr2line. It uses dwarf debug information to resolve the addresses provided by the backtrace to line numbers. https://github.com/yazd/backtrace-d I also have some code that reads elf and dwarf, but it isn't pretty. It can do the same thing that addr2line does.
Nov 09 2013
parent "aldanor" <i.s.smirnov gmail.com> writes:
On Sunday, 10 November 2013 at 07:01:57 UTC, yazd wrote:
 I've implemented a simple thing using addr2line. It uses dwarf 
 debug information to resolve the addresses provided by the 
 backtrace to line numbers.

 https://github.com/yazd/backtrace-d
Very cool, thanks, will check it out later today and report back. Wondering if there any chances of something like that being provided by the standard D library in the foreseeable future? Because without it, effectively debugging even small-sized projects is nigh impossible and painful.
Nov 15 2013
prev sibling parent reply "deadalnix" <deadalnix gmail.com> writes:
On Monday, 28 October 2013 at 10:43:09 UTC, aldanor wrote:
 Hi all,

 Does anybody know what's the current story with 64-bit Linux 
 backtraces? I've seen a couple of posts here and on 
 stackoverflow (like this 
 http://stackoverflow.com/questions/10527901/d2-not-getting-
ny-backtrace-info), 
 couldn't find any definitive answers for the 64-bit case.

 ./test(pure  safe immutable(char)[] 
 std.exception.enforce!(immutable(char)[]).enforce(immutable(char)[], 
 lazy const(char)[], immutable(char)[], ulong)+0x6a) [0x50a85e]
 ./test(_Dmain+0x17f) [0x4a188b]
 ./test(extern (C) int rt.dmain2._d_run_main(int, char**, extern 
 (C) int function(char[][])*).void runMain()+0x18) [0x529740]
 ./test(extern (C) int rt.dmain2._d_run_main(int, char**, extern 
 (C) int function(char[][])*).void tryExec(scope void 
 delegate())+0x2a) [0x529272]
 ./test(extern (C) int rt.dmain2._d_run_main(int, char**, extern 
 (C) int function(char[][])*).void runAll()+0x40) [0x529790]
 ./test(extern (C) int rt.dmain2._d_run_main(int, char**, extern 
 (C) int function(char[][])*).void tryExec(scope void 
 delegate())+0x2a) [0x529272]
 ./oracle(_d_run_main+0x1ae) [0x52922e]
 ./test(main+0x17) [0x52907b]
 /lib64/libc.so.6(__libc_start_main+0xe6) [0x7f87dd21dc36]


 Note: I have the -L--export-dynamic flag enabled in dmd.conf, 
 but it doesn't seem to do much; I'm running dmd64 v2.063.2.
I have the project to improve this for D. And I'll do it one day :D https://github.com/bombela/backward-cpp
Oct 30 2013
parent reply Martin Nowak <code dawg.eu> writes:
On 10/30/2013 09:59 PM, deadalnix wrote:
 I have the project to improve this for D. And I'll do it one day :D

 https://github.com/bombela/backward-cpp
Awesome stuff. Let me know how we could help you to port this to D. Maybe it's simpler to write a C wrapper?
Oct 31 2013
parent "deadalnix" <deadalnix gmail.com> writes:
On Thursday, 31 October 2013 at 18:59:02 UTC, Martin Nowak wrote:
 On 10/30/2013 09:59 PM, deadalnix wrote:
 I have the project to improve this for D. And I'll do it one 
 day :D

 https://github.com/bombela/backward-cpp
Awesome stuff. Let me know how we could help you to port this to D. Maybe it's simpler to write a C wrapper?
I don't plan to port it in the sens I'll translate it to D. Simply propose some patch to make it work with D.
Oct 31 2013