www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.debugger - [ddbg] How do I get further

reply Jason House <jason.james.house gmail.com> writes:
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




->
Dec 06 2007
parent reply Jascha Wetzel <firstname mainia.de> writes:
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




 ->
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: 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.
Dec 07 2007
parent reply Jason House <jason.james.house gmail.com> writes:
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; }
Dec 07 2007
parent Ty Tower <tytower hotmail.com.au> writes:
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
Mar 15 2008