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?

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\
> set prompt >>>>>>cb_gdb:
Ddbg v0.0.4.3 alpha - D Debugger
Copyright (c) 2007 Jascha Wetzel
http://ddbg.mainia.de/
(gdb) >>>>>>cb_gdb:
> show version
>>>>>>cb_gdb:
> set confirm off
>>>>>>cb_gdb:
> set width 0
>>>>>>cb_gdb:
> set height 0
>>>>>>cb_gdb:
> set breakpoint pending on
>>>>>>cb_gdb:
> set print asm-demangle on
>>>>>>cb_gdb:
> set unwindonsignal on
>>>>>>cb_gdb:
> set debugevents on
>>>>>>cb_gdb:
> set new-console on
>>>>>>cb_gdb:
> set disassembly-flavor intel
>>>>>>cb_gdb:
> directory C:/DOCUME~1/simen/MYDOCU~1/Projects/TESTTO~1/
>>>>>>cb_gdb:
> directory C:/
>>>>>>cb_gdb:
> set args buss0708.txt
>>>>>>cb_gdb:
> break "C:/Documents and Settings/simen/My Documents/Projects/TestTopline/in2view.d:418"
Breakpoint 0 at 0x00000000
>>>>>>cb_gdb:
> run
Error: couldn't write breakpoint opcode at :0
>>>>>>cb_gdb:



Jascha Wetzel <[firstname]@mainia.de> Wrote:

> 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?

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

Jascha Wetzel wrote:
> 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?

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

Simen wrote:
> 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\
>> set prompt >>>>>>cb_gdb:
> Ddbg v0.0.4.3 alpha - D Debugger
> Copyright (c) 2007 Jascha Wetzel
> http://ddbg.mainia.de/
> (gdb) >>>>>>cb_gdb:
>> show version
>>>>>>> cb_gdb:
>> set confirm off
>>>>>>> cb_gdb:
>> set width 0
>>>>>>> cb_gdb:
>> set height 0
>>>>>>> cb_gdb:
>> set breakpoint pending on
>>>>>>> cb_gdb:
>> set print asm-demangle on
>>>>>>> cb_gdb:
>> set unwindonsignal on
>>>>>>> cb_gdb:
>> set debugevents on
>>>>>>> cb_gdb:
>> set new-console on
>>>>>>> cb_gdb:
>> set disassembly-flavor intel
>>>>>>> cb_gdb:
>> directory C:/DOCUME~1/simen/MYDOCU~1/Projects/TESTTO~1/
>>>>>>> cb_gdb:
>> directory C:/
>>>>>>> cb_gdb:
>> set args buss0708.txt
>>>>>>> cb_gdb:
>> break "C:/Documents and Settings/simen/My Documents/Projects/TestTopline/in2view.d:418"
> Breakpoint 0 at 0x00000000
>>>>>>> cb_gdb:
>> run
> Error: couldn't write breakpoint opcode at :0
>>>>>>> cb_gdb:
> 
> 
> 
> Jascha Wetzel <[firstname]@mainia.de> Wrote:
> 
>> 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?
>