Bug 7454 – Add file and line numbers to Linux stack traces using addr2line

I'm not quite sure what the situation on Windows or other Posix OSes is, but on Linux, D's stack traces lack files and line numbers. We sort of get the file name thanks to the fact that the module name _is_ the file name (or at least close to it) and that ends up as part of the symbol, but the actual file name would still be nice, and we lack the line number regardless. Per this answer on stackoveflow (method #4): http://stackoverflow.com/questions/3151779/how-its-better-to-invoke-gdb-from-program-to-print-its-stacktrace/4611112#4611112 it should be possible to get the file and line number for at least some portion of a stack trace (some lines seem to end up with ??:0 rather than any real information, but that's still better than nothing). I did some experimenting on my own, and it appears that the address printed in the stack trace does indeed work with addr2line with some lines as long as I compile with -g. So, I don't think that we can always have stack traces with file names and line numbers, but we _can_ as long as debug symbols are enabled. As such, I think that we should add file names and line numbers to D's stack traces on Linux. If we can do it for other OSes, we should do it there as well, but I'm opening up this enhancement specifically for Linux because that's the only one for which I have any clue how to do it.

Jonathan, I wrote a script that does the job, you can use it until the bug gets fixed. Just feed it with stack trace and you'll get not only file names and line numbers (in red color), but also the corresponding lines. --------- #!/bin/sh if [[ "$1" == "" || "$2" != "" ]]; then echo "usage: $0 <executable>" exit fi grep -Po "0x[\d\w]+" | addr2line -e "$1" | grep -v "^??" | sed -r 's/(.*):([0-9]*)/printf "\\033[0;31m\0:\\033[0m\n " \&\& sed -n \2p \1 | sed "s\/^ *\/\/"/' | sh --------- Note: lines from stack trace without corresponding debug info are thrown away. In my case for stack trace ./micron() [0x4b4216] ./micron() [0x427941] ./micron() [0x417ffc] ./micron() [0x417f45] ./micron() [0x41899e] ./micron() [0x483931] ./micron() [0x48c282] ./micron() [0x4838b6] ./micron() [0x419320] ./micron() [0x4278e5] ./micron() [0x4d2760] ./micron() [0x4d2335] ./micron() [0x4b8d37] ./micron() [0x4b4b21] ./micron() [0x4b4472] ./micron() [0x4b43fd] it gives the following output: /home/burjui/devel/micron-d/code.d:38: assert(cell); /home/burjui/devel/micron-d/code.d:27: this(in this) /home/burjui/devel/micron-d/code.d:169: e._value = new Value(*_value); /home/burjui/devel/micron-d/types.d:349: this.return_type = return_type.unlessNull(return_type.clone); /home/burjui/devel/micron-d/utils.d:118: return obj is null ? cast(U)null : ret(); /home/burjui/devel/micron-d/types.d:349: this.return_type = return_type.unlessNull(return_type.clone); /home/burjui/devel/micron-d/code.d:485: auto print_type = new FnType((new Void).toExpr, [ FnArg((new Number(1)).toExpr, "x") ], [], true);

Added a $50 bounty

See also issue 11870. We should implement support for decoding DWARF info in druntime itself.

*** This issue has been marked as a duplicate of issue 11870 ***