• nobody (10/10) May 27 2009 dmd v1.045 on Linux, I got error like:
• Jarrett Billingsley (7/17) May 27 2009 Lol, because segfaults aren't a real method of indicating errors.
• nobody (15/19) May 27 2009 Thanks for the hint. I googled it, here's the way to do it:
• Jarrett Billingsley (2/5) May 27 2009 As long as you don't use invalid UTF-8 data in your debugging statements...
• Leandro Lucarella (9/36) May 28 2009 When debugging C++, the stack trace shows the exact point where the

nobody <no where.com> writes:

dmd v1.045 on Linux, I got error like:

Error: 4invalid UTF-8 sequence
Error: std.format int argument expected

Then I run the program under debugger, there is no indication where the error
occurred:

Error: 4invalid UTF-8 sequence

Program exited with code 01.
(gdb) where
No stack.

This is ridiculous: why cannot the library generate segfault instead?

Jarrett Billingsley <jarrett.billingsley gmail.com> writes:

On Wed, May 27, 2009 at 11:13 PM, nobody <no where.com> wrote:
 dmd v1.045 on Linux, I got error like:

 Error: 4invalid UTF-8 sequence
 Error: std.format int argument expected

 Then I run the program under debugger, there is no indication where the error
 occurred:

 Error: 4invalid UTF-8 sequence

 Program exited with code 01.
 (gdb) where
 No stack.

 This is ridiculous: why cannot the library generate segfault instead?

Lol, because segfaults aren't a real method of indicating errors.

From what I understand, you can set GDB to break whenever _d_throw is
called.  I don't know the syntax.

If you don't want to use a debugger, there's always
printf/writefln/Stdout debugging.  Then you can find out what data is
causing the unicode transcoding methods to barf.

nobody <no where.com> writes:

 From what I understand, you can set GDB to break whenever _d_throw is
 called.  I don't know the syntax.

Thanks for the hint.  I googled it, here's the way to do it:

$ objdump -x your.exe | grep throw
0819c1e0 g     F .text	00000217              _d_throw 4

(gdb) break *0x0819c1e0
Breakpoint 1 at 0x819c1e0

(gdb) r
...

(gdb) where


    ()





 If you don't want to use a debugger, there's always
 printf/writefln/Stdout debugging.

using writefln to find writefln errors? ;-)

Jarrett Billingsley <jarrett.billingsley gmail.com> writes:

On Thu, May 28, 2009 at 12:08 AM, nobody <no where.com> wrote:

 If you don't want to use a debugger, there's always
 printf/writefln/Stdout debugging.

 using writefln to find writefln errors? ;-)

As long as you don't use invalid UTF-8 data in your debugging statements ;)

Leandro Lucarella <llucax gmail.com> writes:

nobody, el 28 de mayo a las 04:08 me escribiste:
 From what I understand, you can set GDB to break whenever _d_throw is
 called.  I don't know the syntax.

 
 Thanks for the hint.  I googled it, here's the way to do it:
 
 $ objdump -x your.exe | grep throw
 0819c1e0 g     F .text	00000217              _d_throw 4
 
 (gdb) break *0x0819c1e0
 Breakpoint 1 at 0x819c1e0
 
 (gdb) r
 ...
 
 (gdb) where


     ()



 
 
 If you don't want to use a debugger, there's always
 printf/writefln/Stdout debugging.

 
 using writefln to find writefln errors? ;-)

When debugging C++, the stack trace shows the exact point where the
exception was thrown, so there is a way to get this right in D, I just
don't know how =)


-- 
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------