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?

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.

> 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
#0  0x0819c1e0 in _d_throw@4 ()
#1  0x081b397c in _D3std6format8doFormatFDFwZvAC8TypeInfoPvZv10getFmtStarMFZi
    ()
#2  0x081b2207 in _D3std6format8doFormatFDFwZvAC8TypeInfoPvZv ()
#3  0x081b19c9 in _D3std5stdio7writefxFPS3std1c5stdio6_iobufAC8TypeInfoPviZv ()
#4  0x081b1ac4 in _D3std5stdio6writefFYv ()


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

using writefln to find writefln errors? ;-)

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

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
> #0  0x0819c1e0 in _d_throw@4 ()
> #1  0x081b397c in _D3std6format8doFormatFDFwZvAC8TypeInfoPvZv10getFmtStarMFZi
>     ()
> #2  0x081b2207 in _D3std6format8doFormatFDFwZvAC8TypeInfoPvZv ()
> #3  0x081b19c9 in _D3std5stdio7writefxFPS3std1c5stdio6_iobufAC8TypeInfoPviZv ()
> #4  0x081b1ac4 in _D3std5stdio6writefFYv ()
> 
> 
> > 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)
----------------------------------------------------------------------------