Tydr Schnubbis wrote:
> The windbg that comes with dmd 0.155 is useless for me, because it runs so slow it looks like it hangs when I try to run an app with it.  I didn't change any of it's settings, so it doesn't seem to work out of the box for me.  Anyone else experienced this?

No. I use windbg all the time, and I have a old (slow) machine.

> But windbg 6 (which I got from Microsoft's site) works fine most of the time.  What exactly am I missing out on by not using the old version?

Newer windbg's don't seem to support codeview 4 debug info, which is what dmd generates.

> Would be even nicer if the D runtime would print line numbers itself on access violations. Or a full stack trace. :)

There's a patch to do that you can install.

Walter Bright wrote:
> Tydr Schnubbis wrote:
>> The windbg that comes with dmd 0.155 is useless for me, because it runs so slow it looks like it hangs when I try to run an app with it.  I didn't change any of it's settings, so it doesn't seem to work out of the box for me.  Anyone else experienced this?
> 
> No. I use windbg all the time, and I have a old (slow) machine.
> 
>> But windbg 6 (which I got from Microsoft's site) works fine most of the time.  What exactly am I missing out on by not using the old version?
> 
> Newer windbg's don't seem to support codeview 4 debug info, which is what dmd generates.
> 
>> Would be even nicer if the D runtime would print line numbers itself on access violations. Or a full stack trace. :)
> 
> There's a patch to do that you can install.

I take it you mean this one:
http://www.digitalmars.com/d/archives/digitalmars/D/32313.html

It's for dmd 0.144, and seem to be some missings symbols from the later versions of phobos.  I hope the author will update it sometime.  Could be very handy.

I got this error:

debug\lib\pipestream.obj(pipestream)
 Error 42: Symbol Undefined _D3std6stream6Stream6isOpenFZx
debug\lib\pipestream.obj(pipestream)
 Error 42: Symbol Undefined _D3std6stream6Stream3eofFZx
debug\serverlist.obj(serverlist)
 Error 42: Symbol Undefined _D3std6thread6Thread5_ctorFDFZikZC3std6thread6Thread

--- errorlevel 3

Tydr Schnubbis wrote:
> I got this error:
> 
> debug\lib\pipestream.obj(pipestream)
>  Error 42: Symbol Undefined _D3std6stream6Stream6isOpenFZx
> debug\lib\pipestream.obj(pipestream)
>  Error 42: Symbol Undefined _D3std6stream6Stream3eofFZx
> debug\serverlist.obj(serverlist)
>  Error 42: Symbol Undefined _D3std6thread6Thread5_ctorFDFZikZC3std6thread6Thread

recompiling the patch should do it.

Walter Bright wrote:
> Tydr Schnubbis wrote:
>> The windbg that comes with dmd 0.155 is useless for me, because it runs so slow it looks like it hangs when I try to run an app with it.  I didn't change any of it's settings, so it doesn't seem to work out of the box for me.  Anyone else experienced this?
> 
> No. I use windbg all the time, and I have a old (slow) machine.
> 
>> But windbg 6 (which I got from Microsoft's site) works fine most of the time.  What exactly am I missing out on by not using the old version?
> 
> Newer windbg's don't seem to support codeview 4 debug info, which is what dmd generates.
> 
>> Would be even nicer if the D runtime would print line numbers itself on access violations. Or a full stack trace. :)
> 
> There's a patch to do that you can install.

Walter, is there any reason that the patch can't be incorporated into Phobos? Together with the -cov option (!), it does 99.9% of everything I've ever used a debugger for, and does it much more conveniently, too.
It's great to have windbug for the last 0.1%, of course.

Don Clugston wrote:
> Walter, is there any reason that the patch can't be incorporated into Phobos? Together with the -cov option (!), it does 99.9% of everything I've ever used a debugger for, and does it much more conveniently, too.
> It's great to have windbug for the last 0.1%, of course.

Sloth on my part.

> Newer windbg's don't seem to support codeview 4 debug info, which is what dmd generates.

What about Visual Studio 2003?
I've tried it with my D code, and it seems to me that
it knows everything windbg knows.
I will look into this further... also with VS2005. I've just tried the
debugger that's all.

Also, is there some problem, maybe a known one, with try cathc blocks and
debugging.
With windbg, after an error in a try block, it didn't stepped into catch,
but signalled an exception. I this normal?
(I will check it with VS too.)

ElfQT

"ElfQT" <dethjunk@yahoo.com> wrote in message news:e3ftla$1nec$1@digitaldaemon.com...
>> Newer windbg's don't seem to support codeview 4 debug info, which is what dmd generates.
>
> What about Visual Studio 2003?
> I've tried it with my D code, and it seems to me that
> it knows everything windbg knows.
> I will look into this further... also with VS2005. I've just tried the
> debugger that's all.

I've tried to debug external executables in VS2003, but it only seems to be able to attach to currently-running processes, making it useless for debugging most things (i.e. pretty much anything that's not a GUI app and which doesn't crash immediately).  Can you shed some light on this?

Instead, I use VS6, in which you can just open an EXE file, and start debugging it.

In article <e3g20i$1udh$1@digitaldaemon.com>, Jarrett Billingsley says...
>
>"ElfQT" <dethjunk@yahoo.com> wrote in message news:e3ftla$1nec$1@digitaldaemon.com...
>>> Newer windbg's don't seem to support codeview 4 debug info, which is what dmd generates.
>>
>> What about Visual Studio 2003?
>> I've tried it with my D code, and it seems to me that
>> it knows everything windbg knows.
>> I will look into this further... also with VS2005. I've just tried the
>> debugger that's all.
>
>I've tried to debug external executables in VS2003, but it only seems to be able to attach to currently-running processes, making it useless for debugging most things (i.e. pretty much anything that's not a GUI app and which doesn't crash immediately).  Can you shed some light on this?
>
>Instead, I use VS6, in which you can just open an EXE file, and start debugging it.
>

I'm only familiar with VS6* myself, but I vaguely recall that it has a properties panel for the current project, where you can set the EXE name to run when debugging.  After setting it, the IDE just hooks that program into the debugger when you start a debugging session.  Perhaps there's something similar in the more recent versions of visual studio for this.

* - I really thing MS had it right with version 6.  Why they had to go and change it up and make it resource hog is beyond me.

- EricAnderton at yahoo

Walter Bright wrote:
> Tydr Schnubbis wrote:
>> The windbg that comes with dmd 0.155 is useless for me, because it runs so slow it looks like it hangs when I try to run an app with it.  I didn't change any of it's settings, so it doesn't seem to work out of the box for me.  Anyone else experienced this?
> 
> No. I use windbg all the time, and I have a old (slow) machine.
> 
Anyone have a link to windbg 5?  The version 4.0 that comes with dmd doesn't work for me. I'm about to give up my project, because printf debugging takes ages...

> I've tried to debug external executables in VS2003, but it only seems to
> be
> able to attach to currently-running processes, making it useless for
> debugging most things (i.e. pretty much anything that's not a GUI app and
> which doesn't crash immediately).  Can you shed some light on this?

Here's a samlpe VS2003 solution. Open, Build, set breakpoint, and press F5.

http://elfqt.synthetik.hu/szallit/D/D_DX_Tut05_Textures.zip

ElfQT