I've gotten fed up of debugging without a debugger with D.  I tried downloading ddbg for my latest bugs.

I'm doing this very nievely, ddbg myProg.exe then hit 'r'.

Following symbol errors for dll (and some program output), I get an exception error but then don't know how to handle it.  No function or (usable) line of code is given for the error.  1602 is the end of the file and at a benign function.  I copied/pasted the end of the session below.  How can I go further?  Generic tips are better than those that rely on the nature of my changes (adding scope to lots of local variable declarations)

Unhandled D Exception (tango.core.Exception.FinalizeException
 "Finalization error") at KERNEL32.dll (0x7c812a5b) thread(4044)
->us
#0 ?? () at game\go.d:1602 from KERNEL32.dll
#1 0x0043594c in __d_throw@4 () at game\go.d:1602 from deh
#2 0x00434e7b in __d_callfinalizer () at game\go.d:1602 from lifetime
#3 0x0041fe5c in  game.go.__modtest () at game\go.d:1602
->

Jason House wrote:
> I've gotten fed up of debugging without a debugger with D.  I tried downloading ddbg for my latest bugs.
> 
> I'm doing this very nievely, ddbg myProg.exe then hit 'r'.
> 
> Following symbol errors for dll (and some program output), I get an exception error but then don't know how to handle it.  No function or (usable) line of code is given for the error.  1602 is the end of the file and at a benign function.  I copied/pasted the end of the session below.  How can I go further?  Generic tips are better than those that rely on the nature of my changes (adding scope to lots of local variable declarations)
> 
> Unhandled D Exception (tango.core.Exception.FinalizeException
>  "Finalization error") at KERNEL32.dll (0x7c812a5b) thread(4044)
> ->us
> #0 ?? () at game\go.d:1602 from KERNEL32.dll
> #1 0x0043594c in __d_throw@4 () at game\go.d:1602 from deh
> #2 0x00434e7b in __d_callfinalizer () at game\go.d:1602 from lifetime
> #3 0x0041fe5c in  game.go.__modtest () at game\go.d:1602
> ->

If the line number is the end of the file, it may be that the error is
generated in code the compiler generates implicitly. This code is
appended at the end of the module.
In this case there is another problem, though. the stacktrace is
obviously not complete. A complete stacktrace looks somewhat like this:
#0 _Dmain () at main.d:6
#1 0x004020d0 in _main () from dmain2
#2 0x0040b66d in _mainCRTStartup () from constart
#3 0x76d919f1 in ?? () from KERNEL32.dll
#4 0x7725d109 in ?? () from ntdll.dll

It starts in ntdll.dll because this is where processes are managed. In
KERNEL32.dll is the routine that launches a process. _mainCRTStartup and
_main are D runtime functions wrapping the program's main(), and finally
there is main.
All of those are missing in your case. There are several reasons why
this can happen (including bugs in ddbg), but i can' tell from the log
how you got there.

So here is what i'd do next:
__modtest is an implicitly generated function of the tango runtime that contains the module's unittests. Therefore, the problem has to be related to that in some way.
If the code itself doesn't help, you can look at the output of obj2asm (a tool which comes with dmd) and find the symbol there. This is only an
option if you know some assembler, though.
Another option is to check what portions of your code can possibly throw a FinalizeException. Set breakpoints on all of them, debug again and
step over them until you found it.

I'm also interested in reproducing this problem myself, because of the truncated stacktrace. If you can create a small testcase, i'd appreciate you sending me it.

Jascha Wetzel Wrote:
> I'm also interested in reproducing this problem myself, because of the truncated stacktrace. If you can create a small testcase, i'd appreciate you sending me it.

I've finally nailed it down to a simple file.  Sometimes, this will crash dmd 1.018.  Other times it's just an executable that crashes.  I have not yet tried it with a newer dmd.  It never gets into main, which may explain the short stack output.  I have not tested this with phobos either (only tango 0.99).

version=crash;
//version=work1;
//version=work2;
//version=work3;

interface I{
}

class C : public I{
}

unittest{
        version(crash) scope I def = new C;
        version(work1) scope C def = new C;
        version(work2)       I def = new C;
        version(work3)       C def = new C;
}

int main(){
        return 0;
}

Jason House Wrote:

> Jascha Wetzel Wrote:
> > I'm also interested in reproducing this problem myself, because of the truncated stacktrace. If you can create a small testcase, i'd appreciate you sending me it.
> 
> I've finally nailed it down to a simple file.  Sometimes, this will crash dmd 1.018.  Other times it's just an executable that crashes.  I have not yet tried it with a newer dmd.  It never gets into main, which may explain the short stack output.  I have not tested this with phobos either (only tango 0.99).
> 
> version=crash;
> //version=work1;
> //version=work2;
> //version=work3;
> 
> interface I{
> }
> 
> class C : public I{
> }
> 
> unittest{
>         version(crash) scope I def = new C;
>         version(work1) scope C def = new C;
>         version(work2)       I def = new C;
>         version(work3)       C def = new C;
> }
> 
> int main(){
>         return 0;
> }
appears to compile in 1.027 OK Linux machine