DMD sometimes generates faulty debug lines information

[Jascha Wetzel]

Everyone using Ddbg with larger than tiny test-programs has probably
experienced this.
What you'll notice is, that although you set a breakopint at some line x
(and the breakpoint is actually set at that line, not just skipping
non-instruction lines), the debugger will break at some other line y > x.
This and similar behaviour has been observed in larger programs (usually
with a lot of modules). I'm currently trying to narrow it down to a test
case, but without success, so far. I'll have to downsize my larger
project step by step...

Has anyone seen something like this in as-small-as-possible programs?

[Simen]

I don't know if its related, but in my current project ddbg stopped working with breakpoints altogether:

Command-line: C:\ddbg\ddbg_gdb.exe -nx -fullname -quiet -args bin/Debug/TestTopline.exe
Working dir : C:\Documents and Settings\simen\My Documents\Projects\TestTopline\
Ddbg v0.0.4.3 alpha - D Debugger
Copyright (c) 2007 Jascha Wetzel
http://ddbg.mainia.de/

show version
set confirm off
set width 0
set height 0
set breakpoint pending on
set print asm-demangle on
set unwindonsignal on
set debugevents on
set new-console on
set disassembly-flavor intel
directory C:/DOCUME~1/simen/MYDOCU~1/Projects/TESTTO~1/
directory C:/
set args buss0708.txt
break "C:/Documents and Settings/simen/My Documents/Projects/TestTopline/in2view.d:418"

Breakpoint 0 at 0x00000000

run

Error: couldn't write breakpoint opcode at :0

Everyone using Ddbg with larger than tiny test-programs has probably
experienced this.
What you'll notice is, that although you set a breakopint at some line x
(and the breakpoint is actually set at that line, not just skipping
non-instruction lines), the debugger will break at some other line y > x.
This and similar behaviour has been observed in larger programs (usually
with a lot of modules). I'm currently trying to narrow it down to a test
case, but without success, so far. I'll have to downsize my larger
project step by step...
Has anyone seen something like this in as-small-as-possible programs?

[Jascha Wetzel]

this problem probably has the same cause.
could you try 0.0.5, and tell me if the problem persists?

Post by Simen
Command-line: C:\ddbg\ddbg_gdb.exe -nx -fullname -quiet -args bin/Debug/TestTopline.exe
Working dir : C:\Documents and Settings\simen\My Documents\Projects\TestTopline\
Ddbg v0.0.4.3 alpha - D Debugger
Copyright (c) 2007 Jascha Wetzel
http://ddbg.mainia.de/

show version
set confirm off
set width 0
set height 0
set breakpoint pending on
set print asm-demangle on
set unwindonsignal on
set debugevents on
set new-console on
set disassembly-flavor intel
directory C:/DOCUME~1/simen/MYDOCU~1/Projects/TESTTO~1/
directory C:/
set args buss0708.txt
break "C:/Documents and Settings/simen/My Documents/Projects/TestTopline/in2view.d:418"

Breakpoint 0 at 0x00000000

run

Error: couldn't write breakpoint opcode at :0

Everyone using Ddbg with larger than tiny test-programs has probably
experienced this.
What you'll notice is, that although you set a breakopint at some line x
(and the breakpoint is actually set at that line, not just skipping
non-instruction lines), the debugger will break at some other line y > x.
This and similar behaviour has been observed in larger programs (usually
with a lot of modules). I'm currently trying to narrow it down to a test
case, but without success, so far. I'll have to downsize my larger
project step by step...
Has anyone seen something like this in as-small-as-possible programs?

[Jascha Wetzel]

this is solved in Ddbg 0.0.5
I was wrong - DMD's codeview info for source lines is fine.

Post by Jascha Wetzel
Everyone using Ddbg with larger than tiny test-programs has probably
experienced this.
What you'll notice is, that although you set a breakopint at some line x
(and the breakpoint is actually set at that line, not just skipping
non-instruction lines), the debugger will break at some other line y > x.
This and similar behaviour has been observed in larger programs (usually
with a lot of modules). I'm currently trying to narrow it down to a test
case, but without success, so far. I'll have to downsize my larger
project step by step...
Has anyone seen something like this in as-small-as-possible programs?