www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.debugger - Bug in ddbg: incorrect stack frame

reply Ary Manzana <ary esperanto.org.ar> writes:
Hi!

When setting a breakpoint at the start of a function (where the name of 
the function is) the stack frame listing (us) is incorrect: it dosen't 
include the before-last stack frame.

Example file 1 (chau.d):

----------------------------------------------------
module chau;

void foo() {            // Line 3
	bar();
}

void main(char[][] args) {
	foo();          // Line 8
}
----------------------------------------------------


C:\d\proj>ddbg chau
Ddbg 0.08 beta - D Debugger
Copyright (c) 2007 Jascha Wetzel
see http://ddbg.mainia.de/doc.html for documentation

Loading symbols from chau
->bp chau:3
Breakpoint set: chau.d:3 0x402010
->r
ntdll.dll loaded
KERNEL32.dll loaded
USER32.dll loaded
GDI32.dll loaded
Breakpoint 0 hit at chau.d:3 0x402010
void foo() {
->us






Should be:







Example file 2:

----------------------------------------------------
module chau;

void bar() {             // Line 3
}

void foo() {
	bar();           // Line 7
}

void main(char[][] args) {
	foo();           // Line 11
}
----------------------------------------------------


C:\d\proj>ddbg chau
Ddbg 0.08 beta - D Debugger
Copyright (c) 2007 Jascha Wetzel
see http://ddbg.mainia.de/doc.html for documentation

Loading symbols from chau
->bp hola:3
Soure file "hola" not found
->bp chau:3
Breakpoint set: chau.d:3 0x402010
->r
ntdll.dll loaded
KERNEL32.dll loaded
USER32.dll loaded
GDI32.dll loaded
Breakpoint 0 hit at chau.d:3 0x402010
void bar() {
->us







Should be:






Apr 27 2007
parent reply Jascha Wetzel <"[firstname]" mainia.de> writes:
The stacktrace prints the function that contains the instruction pointer
of each frame, not the function that allocated the frame.
The code that corresponds to the line where the function is declared
contains the enter opcode that allocates the stack frame for that
function. That means that the frame does not exist until the next line.
Therefore your proposed stacktrace isn't correct at that position.
But I agree that the current version is misleading.

Instead of
<frame no.> <function containing IP> [at file:line | from module]
it should be
<frame no.> <function that created the frame> [at file:line | from module]

In your example the ST would then be (note that line=3 in frame 0)





i'll fix this in the next release.

BTW: did you use DMD 1.010 or older? he args parameter should be
expanded correctly else...

Ary Manzana wrote:
 Hi!
 
 When setting a breakpoint at the start of a function (where the name of
 the function is) the stack frame listing (us) is incorrect: it dosen't
 include the before-last stack frame.
 
 Example file 1 (chau.d):
 
 ----------------------------------------------------
 module chau;
 
 void foo() {            // Line 3
     bar();
 }
 
 void main(char[][] args) {
     foo();          // Line 8
 }
 ----------------------------------------------------
 

 C:\d\proj>ddbg chau
 Ddbg 0.08 beta - D Debugger
 Copyright (c) 2007 Jascha Wetzel
 see http://ddbg.mainia.de/doc.html for documentation
 
 Loading symbols from chau
 ->bp chau:3
 Breakpoint set: chau.d:3 0x402010
 ->r
 ntdll.dll loaded
 KERNEL32.dll loaded
 USER32.dll loaded
 GDI32.dll loaded
 Breakpoint 0 hit at chau.d:3 0x402010
 void foo() {
 ->us





 
 Should be:





 
 
 Example file 2:
 
 ----------------------------------------------------
 module chau;
 
 void bar() {             // Line 3
 }
 
 void foo() {
     bar();           // Line 7
 }
 
 void main(char[][] args) {
     foo();           // Line 11
 }
 ----------------------------------------------------
 

 C:\d\proj>ddbg chau
 Ddbg 0.08 beta - D Debugger
 Copyright (c) 2007 Jascha Wetzel
 see http://ddbg.mainia.de/doc.html for documentation
 
 Loading symbols from chau
 ->bp hola:3
 Soure file "hola" not found
 ->bp chau:3
 Breakpoint set: chau.d:3 0x402010
 ->r
 ntdll.dll loaded
 KERNEL32.dll loaded
 USER32.dll loaded
 GDI32.dll loaded
 Breakpoint 0 hit at chau.d:3 0x402010
 void bar() {
 ->us






 
 Should be:






Apr 27 2007
parent reply Ary Manzana <ary esperanto.org.ar> writes:
Jascha Wetzel escribió:
 The stacktrace prints the function that contains the instruction pointer
 of each frame, not the function that allocated the frame.
 The code that corresponds to the line where the function is declared
 contains the enter opcode that allocates the stack frame for that
 function. That means that the frame does not exist until the next line.
 Therefore your proposed stacktrace isn't correct at that position.
Thanks for the clarification.
 But I agree that the current version is misleading.
 
 Instead of
 <frame no.> <function containing IP> [at file:line | from module]
 it should be
 <frame no.> <function that created the frame> [at file:line | from module]
 
 In your example the ST would then be (note that line=3 in frame 0)




 
 i'll fix this in the next release.
Thanks!
 
 BTW: did you use DMD 1.010 or older? he args parameter should be
 expanded correctly else...
What do you mean by expanded correctly? I just downloaded dmd 1.014 and the args parameters is shown exactly the same. Should I see the args as an array literal (args = ["arg1":"value1"], etc.) ?
Apr 27 2007
parent reply Jascha Wetzel <"[firstname]" mainia.de> writes:
yes, example:

import std.stdio;
void foo() {
    writefln("asdf");
}
void main(char[][] args) {
    foo();
}


debugging it:

->bp c:3
Breakpoint set: chau.d:3 0x402013
->r
...
Breakpoint 0 hit at chau.d:3 0x402013
    writefln("asdf");
->us


  [0] = "C:\\Documents and Settings\\jascha\\My
Documents\\working\\chau.exe"
}) at chau.d:6





Ary Manzana wrote:
 Jascha Wetzel escribió:
 The stacktrace prints the function that contains the instruction pointer
 of each frame, not the function that allocated the frame.
 The code that corresponds to the line where the function is declared
 contains the enter opcode that allocates the stack frame for that
 function. That means that the frame does not exist until the next line.
 Therefore your proposed stacktrace isn't correct at that position.
Thanks for the clarification.
 But I agree that the current version is misleading.

 Instead of
 <frame no.> <function containing IP> [at file:line | from module]
 it should be
 <frame no.> <function that created the frame> [at file:line | from
 module]

 In your example the ST would then be (note that line=3 in frame 0)





 i'll fix this in the next release.
Thanks!
 BTW: did you use DMD 1.010 or older? he args parameter should be
 expanded correctly else...
What do you mean by expanded correctly? I just downloaded dmd 1.014 and the args parameters is shown exactly the same. Should I see the args as an array literal (args = ["arg1":"value1"], etc.) ?
Apr 27 2007
parent reply Ary Manzana <ary esperanto.org.ar> writes:
Yes, sorry, I didn't install dmd correctly.

It's great that strings and arrays are printed this way now.

Jascha Wetzel escribió:
 yes, example:
 
 import std.stdio;
 void foo() {
     writefln("asdf");
 }
 void main(char[][] args) {
     foo();
 }
 
 
 debugging it:
 
 ->bp c:3
 Breakpoint set: chau.d:3 0x402013
 ->r
 ...
 Breakpoint 0 hit at chau.d:3 0x402013
     writefln("asdf");
 ->us


   [0] = "C:\\Documents and Settings\\jascha\\My
 Documents\\working\\chau.exe"
 }) at chau.d:6



 
 
 Ary Manzana wrote:
 Jascha Wetzel escribió:
 The stacktrace prints the function that contains the instruction pointer
 of each frame, not the function that allocated the frame.
 The code that corresponds to the line where the function is declared
 contains the enter opcode that allocates the stack frame for that
 function. That means that the frame does not exist until the next line.
 Therefore your proposed stacktrace isn't correct at that position.
Thanks for the clarification.
 But I agree that the current version is misleading.

 Instead of
 <frame no.> <function containing IP> [at file:line | from module]
 it should be
 <frame no.> <function that created the frame> [at file:line | from
 module]

 In your example the ST would then be (note that line=3 in frame 0)





 i'll fix this in the next release.
Thanks!
 BTW: did you use DMD 1.010 or older? he args parameter should be
 expanded correctly else...
What do you mean by expanded correctly? I just downloaded dmd 1.014 and the args parameters is shown exactly the same. Should I see the args as an array literal (args = ["arg1":"value1"], etc.) ?
Apr 27 2007
parent Charlie <charlie.fats gmail.com> writes:
Yea that is awesome :).

Ary Manzana wrote:
 Yes, sorry, I didn't install dmd correctly.
 
 It's great that strings and arrays are printed this way now.
 
 Jascha Wetzel escribió:
 yes, example:

 import std.stdio;
 void foo() {
     writefln("asdf");
 }
 void main(char[][] args) {
     foo();
 }


 debugging it:

 ->bp c:3
 Breakpoint set: chau.d:3 0x402013
 ->r
 ...
 Breakpoint 0 hit at chau.d:3 0x402013
     writefln("asdf");
 ->us


   [0] = "C:\\Documents and Settings\\jascha\\My
 Documents\\working\\chau.exe"
 }) at chau.d:6





 Ary Manzana wrote:
 Jascha Wetzel escribió:
 The stacktrace prints the function that contains the instruction 
 pointer
 of each frame, not the function that allocated the frame.
 The code that corresponds to the line where the function is declared
 contains the enter opcode that allocates the stack frame for that
 function. That means that the frame does not exist until the next line.
 Therefore your proposed stacktrace isn't correct at that position.
Thanks for the clarification.
 But I agree that the current version is misleading.

 Instead of
 <frame no.> <function containing IP> [at file:line | from module]
 it should be
 <frame no.> <function that created the frame> [at file:line | from
 module]

 In your example the ST would then be (note that line=3 in frame 0)





 i'll fix this in the next release.
Thanks!
 BTW: did you use DMD 1.010 or older? he args parameter should be
 expanded correctly else...
What do you mean by expanded correctly? I just downloaded dmd 1.014 and the args parameters is shown exactly the same. Should I see the args as an array literal (args = ["arg1":"value1"], etc.) ?
Apr 27 2007