Re: winedbg: output of the bt command misses sometimes a frame

[Hin-Tak Leung]

--- On Sat, 6/2/10, Bernhard Übelacker bernha...@vr-web.de wrote:

 Hello,
 as I was debugging in wine I wondered if following
 behaviour is intended or
 could be considered a bug (and should be filed in
 bugtracker?).
 
 When the debugger's current position is on the opening
 curly bracket of a
 function a bt command writes a different stack as if the
 current position
 is on the next instruction in this function.

I think you mis-understand how compiler and debugger works. Curly brackets 
delimit blocks of code but do not correspond to any machine instructions 
themselves, and is hence removed during compilation and execution. So debuggers 
are supposed to skip over them and behaves as if they don't exist during code 
inspection.

 What me makes wonder is the frame 0 is always correct but
 the calling
 function is not in the stack at all in the first bt:
 
 
 Wine-dbgbt
 Backtrace:
 =0 0x7ebe3622 IsWindow(hwnd=0x20060)
 [/home/bernhard/data/entwicklung/2010/wine/wine-git/dlls/user32/win.c:2503]
 in user32 (0x0033b500)
   1 0x7e25429d create_window16+0x5c(cs=0x33b53c,
 className=QWidget, instance=0x40, unicode=1)
 [/home/bernhard/data/entwicklung/2010/wine/wine-git/dlls/user.exe16/message.c:2670]
 in user.exe16 (0x0033b520)
   2 0x7ebe0f91 CreateWindowExW+0x7e(exStyle=1024,
 className=QWidget, windowName=pica, style=114032640,
 x=-2147483648, y=-2147483648, width=-2147483648,
 height=-2147483648, parent=(nil), menu=(nil),
 instance=0x40, data=0x0(nil))
 [/home/bernhard/data/entwicklung/2010/wine/wine-git/dlls/user32/win.c:1500]
 in user32 (0x0033b570)
   3 0x650778f3 in qtgui4 (+0x778f3) (0x8000)
 
 
 Wine-dbgnext
 2507if (!(ptr = WIN_GetPtr(
 hwnd ))) return FALSE;
 
 
 Wine-dbgbt
 Backtrace:
 =0 0x7ebe3637 IsWindow+0x15(hwnd=0x20060)
 [/home/bernhard/data/entwicklung/2010/wine/wine-git/dlls/user32/win.c:2507]
 in user32 (0x0033b2b0)
   1 0x7ebe0bda WIN_CreateWindowEx+0x1201(cs=0x33b53c,
 className=QWidget, module=0x40, unicode=1)
 [/home/bernhard/data/entwicklung/2010/wine/wine-git/dlls/user32/win.c:1406]
 in user32 (0x0033b500)
   2 0x7e25429d create_window16+0x5c(cs=0x33b53c,
 className=QWidget, instance=0x40, unicode=1)
 [/home/bernhard/data/entwicklung/2010/wine/wine-git/dlls/user.exe16/message.c:2670]
 in user.exe16 (0x0033b520)
   3 0x7ebe0f91 CreateWindowExW+0x7e(exStyle=1024,
 className=QWidget, windowName=pica, style=114032640,
 x=-2147483648, y=-2147483648, width=-2147483648,
 height=-2147483648, parent=(nil), menu=(nil),
 instance=0x40, data=0x0(nil))
 [/home/bernhard/data/entwicklung/2010/wine/wine-git/dlls/user32/win.c:1500]
 in user32 (0x0033b570)
   4 0x650778f3 in qtgui4 (+0x778f3) (0x8000)
 
 
 Wine-dbg
 
 
 Kind regards
 Bernhard
 
 
 


  

Re: winedbg: output of the bt command misses sometimes a frame

[Eric Pouech]

Bernhard Übelacker a écrit :

Hello,
as I was debugging in wine I wondered if following behaviour is intended or
could be considered a bug (and should be filed in bugtracker?).

When the debugger's current position is on the opening curly bracket of a
function a bt command writes a different stack as if the current position
is on the next instruction in this function.

What me makes wonder is the frame 0 is always correct but the calling
function is not in the stack at all in the first bt:

  

this is likely because the prolog of IsWindow hasn't been run yet
try next (while on first {
and you should get a decent backtrace

actually, on i386, at the point you're considering
eip : is already in new function
but stack (ebp, esp) hasn't been initialized yet to new function = the 
prolog does it


actually, this is mainly due to the fact that winedbg doesn't do lots of 
magic about guessing prolog size, except when debug information is PDB 
(in that case, this very information is in the debug format)
we used to do some weird heuristics... like setting break address for 
function foo at second line number for this function, which is wrong of 
course
real fix would be (as gdb does in some cases) to disassembly the first 
bytes of the functions to guess the prolog size


A+

--
Eric Pouech
The problem with designing something completely foolproof is to underestimate the 
ingenuity of a complete idiot. (Douglas Adams)