On Wednesday 15 December 2010 02:28:56 spir wrote:
> On Tue, 14 Dec 2010 10:13:03 -0800
>
> Jonathan M Davis <jmdavisp...@gmx.com> wrote:
> > On Tuesday, December 14, 2010 09:48:14 spir wrote:
> > > Hello,
> > >
> > >
> > > Am I the only one who gets, as only kind of runtime errors,
> > > spectacularly helpful messages like:
> > >
> > > int f () {return 0;}
> > > void main () {
> > >
> > > assert (f() == 1);
> > >
> > > }
> > > ==>
> > > s...@o:~/prog/d/Text$ ./__trials__
> > > core.exception.asserter...@__trials__(44): Assertion failure
> > > ----------------
> > > ./__trials__() [0x804bb86]
> > > ./__trials__() [0x8049642]
> > > ./__trials__() [0x804960b]
> > > ./__trials__() [0x804bd76]
> > > ./__trials__() [0x804bcd0]
> > > ./__trials__() [0x804bdba]
> > > ./__trials__() [0x804bcd0]
> > > ./__trials__() [0x804bc76]
> > > /lib/tls/i686/cmov/libc.so.6(__libc_start_main+0xe6) [0x292bd6]
> > >
> > > Thankfully, D is a static language, so that I have rather few runtime
> > > errors. But what am I missing to get a stack trace? Sometimes, I don't
> > > even have the (last) faulty line of code (dunno why).
> >
> > On Linux, I believe that you need to compile with -L--export-dynamic. I
> > think that that's supposed to be in the version of dmd.conf that comes
> > with the most recent version of dmd, so it should work out of the box
> > (though if you're using an older dmd.conf, then it would be missing).
> > IIRC, stack traces don't work properly on Windows yet (though I don't
> > know exactly what's going on there), so I believe that you're currently
> > out of luck on Windows. However, what you're showing there looks like
> > what you get on Linux if you don't build with -L-- export-dynamic, so
> > I'm guessing that that's your problem.
> >
> > - Jonathan M Davis
>
> Thank you, jonathan. (On Linux, yes) I get now for a prog called "x.d":
>
> s...@o:~/prog/d$ dmd -ofprog -w -debug -unittest -L--export-dynamic prog.d
> s...@o:~/prog/d$ ./prog
> core.exception.asserter...@prog(20): Assertion failure
> ----------------
> ./prog(_d_assertm+0x16) [0x807ca26]
> ./prog(void prog.__assert(int)) [0x807a4ea]
> ./prog(_Dmain+0x17) [0x807a4d3]
> ./prog(extern (C) int rt.dmain2.main(int, char**)) [0x807cc16]
> ./prog(extern (C) int rt.dmain2.main(int, char**)) [0x807cb70]
> ./prog(extern (C) int rt.dmain2.main(int, char**)) [0x807cc5a]
> ./prog(extern (C) int rt.dmain2.main(int, char**)) [0x807cb70]
> ./prog(main+0x96) [0x807cb16]
> /lib/tls/i686/cmov/libc.so.6(__libc_start_main+0xe6) [0x23bbd6]
> ./prog() [0x807a3f1]
>
> Much better (if not the friendliest output I've ever seen ;-).
>
> For the following prog, I get:
>
> int element(int[] elements, uint i) {return elements[i];}
> void main () {
> int[] elements = [3,2,1];
> auto e = elements[9];
> }
>
> s...@o:~/prog/d$ dmd -ofprog -w -debug -unittest -L--export-dynamic prog.d
> s...@o:~/prog/d$ ./prog
> core.exception.rangeer...@prog(20): Range violation
> ----------------
> ./prog(_d_array_bounds+0x16) [0x807cad6]
> ./prog(_D4prog7__arrayZ+0x12) [0x807a54a]
> ./prog(_Dmain+0x38) [0x807a524]
> ./prog(extern (C) int rt.dmain2.main(int, char**)) [0x807cc76]
> ./prog(extern (C) int rt.dmain2.main(int, char**)) [0x807cbd0]
> ./prog(extern (C) int rt.dmain2.main(int, char**)) [0x807ccba]
> ./prog(extern (C) int rt.dmain2.main(int, char**)) [0x807cbd0]
> ./prog(main+0x96) [0x807cb76]
> /lib/tls/i686/cmov/libc.so.6(__libc_start_main+0xe6) [0x1ddbd6]
> ./prog() [0x807a401]
>
> Do you have (even) nicer error reports on some OS's or using some switches?
I believe that that's pretty much what stack traces look like at this point.
-gc
is for adding debugging symbols so that you can use something like gdb, so it
shouldn't have any effect on the stack trace. I don't think that there are any
compiler switches that will do anything for you with regards to stack traces.
- Jonathan M Davis
