Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

stack trace missing on assert failure #115

Open
thelastmammoth opened this Issue Jun 7, 2012 · 21 comments

Comments

Projects
None yet
7 participants

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
----------------
Contributor

Trass3r commented Jul 1, 2014

Also on Linux64.

@redstar redstar pushed a commit that referenced this issue Sep 27, 2014

@complexmath complexmath Merge pull request #115 from 9rnsr/fix_cas_test
Use `is` instead of `==` for CAS test
cf40272
Contributor

dmakarov commented Mar 15, 2015

I submitted a pull request ldc-developers/druntime#18 that fixes this issue.

@dmakarov dmakarov referenced this issue in ldc-developers/druntime Mar 15, 2015

Merged

Fix #115: intialize the exception object's info field. #18

Owner

redstar commented Mar 15, 2015

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?

Contributor

dmakarov commented Mar 15, 2015

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.

Contributor

dmakarov commented Mar 15, 2015

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.

Owner

redstar commented Mar 15, 2015

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.

@redstar redstar added a commit that referenced this issue Mar 15, 2015

@redstar redstar Partial fix for issue #115 98eb4cc
Contributor

dmakarov commented Mar 15, 2015

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.

Owner

redstar commented Mar 15, 2015

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

@redstar redstar closed this Mar 15, 2015

Member

JohanEngelen commented Dec 14, 2016 edited

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 JohanEngelen reopened this Dec 14, 2016

Member

JohanEngelen commented Dec 14, 2016

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());
    }
}
Member

kinke commented Dec 14, 2016 edited

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.

Owner

klickverbot commented Dec 14, 2016 edited

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

Member

kinke commented Dec 14, 2016

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

Owner

klickverbot commented Dec 14, 2016

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

Member

kinke commented Dec 14, 2016 edited

:] 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.

Owner

klickverbot commented Dec 14, 2016

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

@kinke kinke closed this in #1920 Dec 15, 2016

Member

JohanEngelen commented Dec 17, 2016

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.

@JohanEngelen JohanEngelen reopened this Dec 17, 2016

Member

kinke commented Dec 17, 2016

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

Member

JohanEngelen commented Dec 18, 2016

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

Member

kinke commented Apr 21, 2017 edited

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.
Owner

klickverbot commented May 6, 2017

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).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment