Ddbg is a Win32 D Debugger

http://ddbg.mainia.de/releases.html

This release supports evaluation of structs and classes.

Looks interesting.  Something that's simpler to use for quick D debugging than windbg and msvc.  As long as the docs will continue to fit on one page, at least.

I tried this:

import std.stdio;
import std.c.stdlib;

void main()
{
	writefln("hello 1");
	free(cast(void*)1);
	writefln("hello 2");
}

I tried setting breakpoints on line 4 and 6, and others too.  But ddbg just crashes when I use the 'bp' command.


Hang on... This is odd, now it crashes when I try to set a breakpoint at line 79 of debuggee.d too.  It didn't do that five minutes ago.  Weird.

it doesn't crash when i do that. maybe you can use the debug build to
get more info (included in the new archive).
there was another issue, though: the source line wasn't detected
correctly with your program. that should be fixed in 0.0.2.2.

http://ddbg.mainia.de/Ddbg-0.0.2.2-alpha.zip

when i debug your program, it looks like this:

C>ddbg.exe torhu.exe
Process started
ntdll.dll loaded
KERNEL32.dll loaded
USER32.dll loaded
GDI32.dll loaded
Unknown breakpoint hit at ntdll.dll (0x7c901230)
->bp t:4
Breakpoint set: torhu.d:4 0x402010
->bp t:6
Breakpoint set: torhu.d:6 0x402013
->r
IMM32.dll loaded
ADVAPI32.dll loaded
RPCRT4.dll loaded
LPK.dll loaded
USP10.dll loaded
msvcrt.dll loaded
Breakpoint 0 hit torhu.d:4 0x402010
void main()
->r
Breakpoint 1 hit torhu.d:6 0x402013
    writefln("hello 1");
->ov
hello 1
torhu.d:7 0x40202a
    free(cast(void*)1);
->
Unhandled Exception: EXCEPTION_ACCESS_VIOLATION(0xc0000005) at multpool
(0x0040bda1)
->q

torhu wrote:
> Looks interesting.  Something that's simpler to use for quick D debugging than windbg and msvc.  As long as the docs will continue to fit on one page, at least.
> 
> I tried this:
> 
> import std.stdio;
> import std.c.stdlib;
> 
> void main()
> {
>     writefln("hello 1");
>     free(cast(void*)1);
>     writefln("hello 2");
> }
> 
> I tried setting breakpoints on line 4 and 6, and others too.  But ddbg just crashes when I use the 'bp' command.
> 
> 
> Hang on... This is odd, now it crashes when I try to set a breakpoint at line 79 of debuggee.d too.  It didn't do that five minutes ago.  Weird.

I tried the new version, still with the small test example I posted.  I tried to debug the debugger with itself.  Not sure if that's what I'm really doing here, though.


I start with: ddbg ddbg_debug.exe crash.exe

->bp 4
Unhandled Exception: EXCEPTION_ACCESS_VIOLATION(0xc0000005) at MFAaZb dbugger.dbugger.parseCommand src\dbugger.d:323 (0x004082ec)



This only happened the first time I tried this.  When I restart the debugger and try again, it just crashes, with an access violation.  This is probably the kind of error that goes away when I reboot windows. Maybe I'll do that later today.

By the way, are you using dmd 1.007?

ah, ok that's partially a bug, partially a bad command.
the correct syntax for bp is "bp [<source file>:<line>] [index]", so
you're missing the source file name. it shouldn't crash either, though...
i'll add this convenience syntax (if only one source file is available)
in the next release. until then use something like bp cr:4, "cr" being a
substring of the source file/module name. use "lsm" to list all
available source module names.

debugging the debugger isn't tested, yet. atm ddbg debugs the debuggee
and all it's child processes. to successfully debug the debugger, it has
 to stay away from the child processes, as those are debugged by the
child - the debugged debugger :)

> By the way, are you using dmd 1.007?
yes. also the 0.0.2 releases are compiled with 1.007

thanks for that feedback.

torhu wrote:
> I tried the new version, still with the small test example I posted.  I tried to debug the debugger with itself.  Not sure if that's what I'm really doing here, though.
> 
> 
> I start with: ddbg ddbg_debug.exe crash.exe
> 
> ->bp 4
> Unhandled Exception: EXCEPTION_ACCESS_VIOLATION(0xc0000005) at MFAaZb
> dbugger.dbugger.parseCommand src\dbugger.d:323 (0x004082ec)
> 
> 
> 
> This only happened the first time I tried this.  When I restart the debugger and try again, it just crashes, with an access violation.  This is probably the kind of error that goes away when I reboot windows. Maybe I'll do that later today.
> 
> By the way, are you using dmd 1.007?

Jascha Wetzel wrote:
> ah, ok that's partially a bug, partially a bad command.
> the correct syntax for bp is "bp [<source file>:<line>] [index]", so
> you're missing the source file name. it shouldn't crash either, though...
> i'll add this convenience syntax (if only one source file is available)
> in the next release. until then use something like bp cr:4, "cr" being a
> substring of the source file/module name. use "lsm" to list all
> available source module names.

Oops.


Another question. My crash example crashes at line 7, at 'free(cast(void*)1);'  But ddbg seems to say it crashes at line 8.  Is this intended?

Unhandled Exception: EXCEPTION_ACCESS_VIOLATION(0xc0000005) at multpool (0x0040bda1)
->us
_Dmain crash.d:8 (0x00402031)
dmain2 (0x0040213c)
constart (0x0040a115)
KERNEL32.dll (0x7c816fd7)
->q

to be precise, ddbg says that it crashes in multpool, which is some function/segment (from minit.obj) free uses. when you unwind the stack after the exception occured, it holds the return address of the call that caused the exception, which is free. therefore the resulting source address is after that call to free.

torhu wrote:
> Jascha Wetzel wrote:
>> ah, ok that's partially a bug, partially a bad command.
>> the correct syntax for bp is "bp [<source file>:<line>] [index]", so
>> you're missing the source file name. it shouldn't crash either, though...
>> i'll add this convenience syntax (if only one source file is available)
>> in the next release. until then use something like bp cr:4, "cr" being a
>> substring of the source file/module name. use "lsm" to list all
>> available source module names.
> 
> Oops.
> 
> 
> Another question. My crash example crashes at line 7, at
> 'free(cast(void*)1);'  But ddbg seems to say it crashes at line 8.  Is
> this intended?
> 
> Unhandled Exception: EXCEPTION_ACCESS_VIOLATION(0xc0000005) at multpool
> (0x0040bda1)
> ->us
> _Dmain crash.d:8 (0x00402031)
> dmain2 (0x0040213c)
> constart (0x0040a115)
> KERNEL32.dll (0x7c816fd7)
> ->q

Jascha Wetzel wrote:
> Ddbg is a Win32 D Debugger
> 
> http://ddbg.mainia.de/releases.html
> 
> This release supports evaluation of structs and classes.

Nice work!  If someone sort out emacs integration I'm sold :-)


Sean

Sean Kelly wrote:
> Jascha Wetzel wrote:
>> Ddbg is a Win32 D Debugger
>>
>> http://ddbg.mainia.de/releases.html
>>
>> This release supports evaluation of structs and classes.
> 
> Nice work!  If someone sort out emacs integration I'm sold :-)
> 
> 
> Sean

Is ddbg's syntax compatible with any one of emacs' debugging modes?
 - gdb
 - dbx
 - xdb
 - jdb
 - sdb
 - pdb

If so, then that mode should just work (in theory).
If not then either
a) ddbg needs a 'compatibility mode' that mimics one of those debugger's interfaces, or
b) a new emacs mode needs to be written

I think a) makes the most sense long term, because if ddbg supported gdb, dbx, or xdb syntax then it should be possible to also use a wide variety of other front-ends like ddd.  (www.gnu.org/software/ddd/)

--bb

yep, i was already thinking of mimicing gdb or MS dbg, but postponed that. i'll add an API in one of the next releases, such that different UIs can be added easily.

Bill Baxter wrote:
> Sean Kelly wrote:
>> Jascha Wetzel wrote:
>>> Ddbg is a Win32 D Debugger
>>>
>>> http://ddbg.mainia.de/releases.html
>>>
>>> This release supports evaluation of structs and classes.
>>
>> Nice work!  If someone sort out emacs integration I'm sold :-)
>>
>>
>> Sean
> 
> Is ddbg's syntax compatible with any one of emacs' debugging modes?
>  - gdb
>  - dbx
>  - xdb
>  - jdb
>  - sdb
>  - pdb
> 
> If so, then that mode should just work (in theory).
> If not then either
> a) ddbg needs a 'compatibility mode' that mimics one of those debugger's
> interfaces, or
> b) a new emacs mode needs to be written
> 
> I think a) makes the most sense long term, because if ddbg supported gdb, dbx, or xdb syntax then it should be possible to also use a wide variety of other front-ends like ddd.  (www.gnu.org/software/ddd/)
> 
> --bb