stack trace missing on assert failure

thelastmammoth commented 12 years ago

the stack trace appears in dmd, not ldmd2/ldc (even with various combination of debug flags): (i'm on osx if that's relevant).

main4.d:

int fun(int x){ assert(x<0); return x+x;}
void main(){int x=fun(10);}

ldmd2 main4 && ./main4                                                                                                  
core.exception.AssertError@main4.d(1): Assertion failure

==> no stack trace

dmd main4 && ./main4                                                                                                
core.exception.AssertError@main4(1): Assertion failure
----------------
5   main4                               0x00000001095d2576 _d_assertm + 42
6   main4                               0x00000001095c2477 void main4.__assert(int) + 23
7   main4                               0x00000001095c2491 int main4.fun(int) + 25
8   main4                               0x00000001095c245a _Dmain + 14
9   main4                               0x00000001095d2ea9 extern (C) int rt.dmain2.main(int, char**).void runMain() + 29
10  main4                               0x00000001095d285e extern (C) int rt.dmain2.main(int, char**).void tryExec(scope void delegate()) + 38
11  main4                               0x00000001095d2ef6 extern (C) int rt.dmain2.main(int, char**).void runAll() + 58
12  main4                               0x00000001095d285e extern (C) int rt.dmain2.main(int, char**).void tryExec(scope void delegate()) + 38
13  main4                               0x00000001095d27e9 main + 237
14  main4                               0x00000001095c2444 start + 52
15  ???                                 0x0000000000000001 0x0 + 1
----------------

Trass3r commented 10 years ago

Also on Linux64.

dmakarov commented 9 years ago

I submitted a pull request https://github.com/ldc-developers/druntime/pull/18 that fixes this issue.

redstar commented 9 years ago

I get a stack trace now but the symbols are still missing (compiled with -g):

core.exception.AssertError@main4.d(3): Assertion failure
----------------
./main4() [0x401ddc]
./main4() [0x401e02]
./main4() [0x40f194]
./main4() [0x40f069]
./main4() [0x40f105]
./main4() [0x40f069]
./main4() [0x40efc8]
./main4() [0x401f28]
/lib64/libc.so.6(__libc_start_main+0xf5) [0x7f66b960edc5]

Do you have an idea why?

dmakarov commented 9 years ago

Not really sure why. I tested on OS X -- the stack trace looks fine (if app is compiled with -g). I'll check on Linux x86_64.

dmakarov commented 9 years ago

By the way, does LDC generated code ever show the stack trace? It might be easier to debug this if there's an example of successful stack trace dumping. Unrelated question: how do you validate pull requests to druntime? It doesn't look like there's an automated travis-ci job triggered for these PRs.

redstar commented 9 years ago

Up to now, I only got a stack trace on Win64 with ldc2 compiled code. IMHO it can be only a stupid problem like the one you fixed. DMD and LDC use Dwarf on Linux.

I validated the PR manually. Fore more complex PRs I create a branch in druntime and ldc to trigger the Travis build.

dmakarov commented 9 years ago

On Linux the symbols are missing for me too. I'll have to check how TraceInfo.toString() is implemented, to figure why the symbols are missing. This is a related issue, but not really about stack not being dumped on assert. I'm not sure -- perhaps, this issue could be closed, and another to be opened (or this one renamed) for the remaining problem.

redstar commented 9 years ago

I think this is a good idea. I opened #863 for the new problem.

JohanEngelen commented 7 years ago

Just tested this and: the problem is back.

(tested on OS X, 0.17.2, 1.0.0, and 1.1.0 do not show stack traces)

JohanEngelen commented 7 years ago

Another testcase (use dmd -run test.d):

import std.json;
import std.stdio;

string pjson(ref JSONValue js)
{
    return js["hhh"].str;
}

void main()
{
    JSONValue js;
    js["hh"] = 10;
    try{
        pjson(js);
    } catch(Exception e){
        writeln(e.toString());
    }
}

kinke commented 7 years ago

It may have something to do with the frame pointer (register EBP/RBP) not always being used/set up (gcc -fomit-frame-pointer); just tested on Win64, where the stack trace is also missing for your example. The unoptimized Win64 ASM for

int main()
{
    int a = 0;
    writefln("Hello LDC2");
    return a;
}

doesn't use RBP at all. Just a guess of mine based on https://github.com/ldc-developers/druntime/blob/ldc/src/core/runtime.d#L522, plus the etc.linux.memoryerror failures seemed to suggest something wrong with RBP too.

dnadlinger commented 7 years ago

Did we ever end up merging https://github.com/weka-io/druntime/commits/9b4a3c05 into mainline LDC? That should make backtraces much reliable.

kinke commented 7 years ago

Nope ;) - are you going to merge or shall I?

dnadlinger commented 7 years ago

Please do. ;) My time budget to spend on LDC right now is far in the negative figures.

kinke commented 7 years ago

:] Alright. Btw I just figured the frame-pointer optimization can be disabled via -disable-fp-elim; I didn't expect it to be enabled by default for non-optimized and even debug builds.

dnadlinger commented 7 years ago

FP elim in debug builds makes little sense – if that is indeed what is happening, I'd say it is a bug.

JohanEngelen commented 7 years ago

Reopening so we won't forget to add a testcase.

I think that -disable-fp-elim should be implicit in -O0 builds, perhaps disabled from -O1 (GCC behavior https://gcc.gnu.org/onlinedocs/gcc-4.9.2/gcc/Optimize-Options.html). Note that the complete backtrace already shows up in debuggers (tested with lldb) when the test is compiled with only -g and breaking on _d_assert.

kinke commented 7 years ago

Oh this isn't fixed at all; the commit message said this doesn't fix #115 - too elaborate for GitHub's AI. ;)

JohanEngelen commented 7 years ago

(it's kindof fixed on OSX with -disable-fp-elim ! So we are closer. )

kinke commented 7 years ago

Update:

Windows: Win64 backtraces are excellent, Win32 wonky, see these examples.
OSX: apparently needs at least -disable-fp-elim, which should be implicit for debug builds. I had a very quick look a while back and IIRC I didn't find anything in the LDC source, so it appeared to be the LLVM default. Peeking at clang code may help.
Linux: function names only show up when linking with --export-dynamic as backtrace_symbols() doesn't read from debuginfos. Known upstream and partially fixed as DMD issue 11870 (which is marked as resolved); DMD uses -L--export-dynamic in its default config file.

dnadlinger commented 7 years ago

The original issue will be fixed with #2097 (macOS assertions). We should probably open a number of more concrete tickets for the remaining issues (e.g. #2098, #2099).

ldc-developers / ldc

stack trace missing on assert failure #115