Thread overview
Re: helpful runtime error messages
Dec 14, 2010
Jonathan M Davis
Dec 15, 2010
spir
Dec 15, 2010
Jesse Phillips
Dec 15, 2010
spir
Dec 15, 2010
Jesse Phillips
Dec 15, 2010
Nick Voronin
Dec 15, 2010
Jonathan M Davis
December 14, 2010
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);
> }
> ==>
> spir@o:~/prog/d/Text$ ./__trials__
> core.exception.AssertError@__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
December 15, 2010
On Tue, 14 Dec 2010 10:13:03 -0800
Jonathan M Davis <jmdavisProg@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);
> > }
> > ==>
> > spir@o:~/prog/d/Text$ ./__trials__
> > core.exception.AssertError@__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":

spir@o:~/prog/d$ dmd -ofprog -w -debug -unittest -L--export-dynamic prog.d
spir@o:~/prog/d$ ./prog
core.exception.AssertError@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];
}

spir@o:~/prog/d$ dmd -ofprog -w -debug -unittest -L--export-dynamic prog.d
spir@o:~/prog/d$ ./prog
core.exception.RangeError@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?


denis
-- -- -- -- -- -- --
vit esse estrany ☣

spir.wikidot.com

December 15, 2010
spir Wrote:

> 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];
> }
> 
> spir@o:~/prog/d$ dmd -ofprog -w -debug -unittest -L--export-dynamic prog.d
> spir@o:~/prog/d$ ./prog
> core.exception.RangeError@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 this is where compiling with -gc (debug info that looks like C) as it should give you line numbers.
December 15, 2010
On Wed, 15 Dec 2010 11:54:28 -0500
Jesse Phillips <jessekphillips+D@gmail.com> wrote:

> spir Wrote:
> 
> > 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];
> > }
> > 
> > spir@o:~/prog/d$ dmd -ofprog -w -debug -unittest -L--export-dynamic prog.d
> > spir@o:~/prog/d$ ./prog
> > core.exception.RangeError@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 this is where compiling with -gc (debug info that looks like C) as it should give you line numbers.

It was already compiled with -gc (removing this switch does not change output). I get a line only for top-level call (the number above point to the calling line in main).


Denis
-- -- -- -- -- -- --
vit esse estrany ☣

spir.wikidot.com

December 15, 2010
On Wednesday 15 December 2010 02:28:56 spir wrote:
> On Tue, 14 Dec 2010 10:13:03 -0800
> 
> Jonathan M Davis <jmdavisProg@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);
> > > 
> > > }
> > > ==>
> > > spir@o:~/prog/d/Text$ ./__trials__
> > > core.exception.AssertError@__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":
> 
> spir@o:~/prog/d$ dmd -ofprog -w -debug -unittest -L--export-dynamic prog.d
> spir@o:~/prog/d$ ./prog
> core.exception.AssertError@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];
> }
> 
> spir@o:~/prog/d$ dmd -ofprog -w -debug -unittest -L--export-dynamic prog.d
> spir@o:~/prog/d$ ./prog
> core.exception.RangeError@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
December 15, 2010
spir Wrote:

> It was already compiled with -gc (removing this switch does not change output). I get a line only for top-level call (the number above point to the calling line in main).

Sorry wasn't on a Linux box to test myself. It might have to do with the error occurring in main, so you already get the line number. I had assumed -gc wasn't used since your compile line is:

> spir@o:~/prog/d$ dmd -ofprog -w -debug -unittest -L--export-dynamic prog.d

Anyway that is the best there is.
December 15, 2010
On Wed, 15 Dec 2010 13:28:56 +0300, spir <denis.spir@gmail.com> wrote:

> spir@o:~/prog/d$ dmd -ofprog -w -debug -unittest -L--export-dynamic prog.d
> spir@o:~/prog/d$ ./prog
> core.exception.RangeError@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?

Trass3r pointed this http://3d.benjamin-thaut.de/?p=15 recently. It prints line numbers on windows. It doesn't go as deep as stacktrace above though. Just

core.exception.RangeError@strace2(5): Range violation
----------------
00 strace2.d::5(16) _Dmain
01 extern (C) int rt.dmain2.main(int, char**) . void runMain() .
02 extern (C) int rt.dmain2.main(int, char**) . void runAll() .
03 main
04 mainCRTStartup
05 RegisterWaitForInputIdle




-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/