[prev in list] [next in list] [prev in thread] [next in thread] 

List:       wine-devel
Subject:    Re: [Q] Status of wine debugger
From:       "Juergen Schmied" <juergen.schmied () debitel ! net>
Date:       2000-10-29 0:53:13
[Download RAW message or body]


> However doing so it looks like:
> 
> 
> 0x405cdf46 (CreateWindowExA+0x46 [win.c:1118])
> 1118          FIXME("BON:Setting up SysHeader32\n");
> Wine-dbg>bt
> Backtrace:
> =>0 0x405cdf46 (CreateWindowExA+0x46(exStyle=0x0, className=0x5f4a5444, \
> windowName=0x0, style=0x40000042, x=0x5f403903, y=0x5f4d1b60, width=0xa10af35d, \
> height=0xa0b2e4a0, parent=0x341c, menu=0x9c70, instance=0x400000, data=0x0) \
> [win.c:1118]) (ebp=4083cde0) 1 0x5f407d8a \
> (COccManager::SplitDialogTemplate+0x6(pTemplate=0x0, ppOleDlgItems=0x5f4a5444) \
> [occmgr.cpp:182]) (ebp=4083ce50) 2 0x5f409a6b (MFC42.DLL.2124+0x46) (ebp=4083ce8c)
> 3 0x5f456a10 (MFC42.DLL.2093+0x2d) (ebp=ffffffff)
> *** Invalid address 0xffffffff (SHLWAPI.DLL..reloc+0x4048dfff)
> 
> I wonder why the stack levels 2 and 3 don't get resolved in Function
> names and looking at the MFC source for occmgr.cpp I think winedbg
> doesn't get things right...
windbg can read pdb files if the debug information of the exe file is not stripped
and the exe file is pointing directly to the pdb file.
If the debuginformation is stripped to a dbg file and there is a record pointing
to the pdb file in the dbg file windgb is not able to load the filename.
I already implemented the missing functionallity but didn't post the code since
it resolves not all functions to the right adresses and i could not find the problem
yet.
A second problem is: the pdb file seems to have a different timestamp than the dbg \
file so I had to disable the code what checks it. To me it looks like the pdb code \
gets a  invalid timestamp from pdb files mostly.
I think I'll post the patch tomorrow anyway. (Have do do some cleanup before and its
a bit late now)
With this patch it reads the pdb file regadless of the timestamp (prints a warning) \
but it displays often wrong function names (some 1000 bytes beside the right name).

juergen


 


[prev in list] [next in list] [prev in thread] [next in thread]