Re: gethostbyname call with 0 length arg
Detlef Riekenberg wrote:
if((!name) && (name[0])) {
Do you really mean that?
"if name is 0, then dereference name"?
--
Christer Palm
Re: winedbg symbols completely screwed
Eric Pouech wrote: Christer Palm wrote: The thing is that I can't see that this is the case here. I have: [EMAIL PROTECTED] ~]$ find ~/.wine/drive_c/ -name "MFC*" -o -name "mfc*" from one of your previous posts: wine: Unhandled page fault on read access to 0x003c at address 0x5f4056dd (thread 0009), starting debugger... WineDbg starting on pid 0x8 Unhandled exception: page fault on read access to 0x003c in 32-bit code (0x5f4056dd). In 32 bit mode. fixme:dbghelp:sffip_cb NIY on 'E:\8168\vc98\mfc\mfc.bbt\src\mfc42.pdb' fixme:dbghelp:sffip_cb NIY on 'C:\hager\Semiolog\Apps\MFC42.PDB' fixme:dbghelp_msc:codeview_parse_type_table Not adding parameters' types to function signature fixme:dbghelp_msc:codeview_parse_type_table Unsupported type-id leaf a fixme:dbghelp_msc:dump : 06 00 0a 00 01 00 50 f1 ..P. fixme:dbghelp_msc:codeview_get_type Returning NULL symt for type-id 1053 Ah, I suppose you mean the 'E:\8168\vc98\mfc\mfc.bbt\src\mfc42.pdb' line. There is no such file. In fact, I don't even have a drive mapping for E:. I've been assuming that winedbg is getting this bogus path from the executable (perhaps the location of MFC42.PDB when MFC42 was originally compiled or something). I ran the ChkMatch tool from www.debuginfo.com to verify that the PDB and DLL really match, and it also confirms that the bogus E: path really comes from MFC42.DLL. This doesn't rule out the (rather unlikely, I would say) possibility that the PDB is corrupt in some other way, of course. Perhaps someone can mail me a "known good" pair of MFC42.DLL/PDB files? [EMAIL PROTECTED] tmp]$ wine ChkMatch.exe -c /home/palm/.wine/drive_c/windows/system/MFC42.DLL /home/palm/.wine/drive_c/hager/Semiolog/Apps/MFC42.PDB ChkMatch - version 1.0 Copyright (C) 2004 Oleg Starodumov http://www.debuginfo.com/ Executable: /home/palm/.wine/drive_c/windows/system/MFC42.DLL Debug info file: /home/palm/.wine/drive_c/hager/Semiolog/Apps/MFC42.PDB Executable: TimeDateStamp: 35889e42 Debug info: 2 ( CodeView ) TimeStamp: 35887c4e Characteristics: 0 MajorVer: 0 MinorVer: 0 Size: 55 RVA: FileOffset: 000f3000 CodeView format: NB10 Signature: 35889e42 Age: 2 PDB File: E:\8168\vc98\mfc\mfc.bbt\src\mfc42.pdb Debug info: 10 ( Unknown ) TimeStamp: Characteristics: 0 MajorVer: 0 MinorVer: 0 Size: 0 RVA: FileOffset: Debug info: Unknown. Debug information file: Format: PDB 2.00 Signature: 35889e42 Age: 2 Result: Matched Regards, -- Christer Palm
Re: winedbg symbols completely screwed
Eric Pouech wrote: Christer Palm wrote: Continuing my debugging efforts, I decided to look some more at the strange symbols I got in the backtrace. Indeed, it seems like winedbg completely screws up the MFC42 symbols. For example, by disassembling from the load address of MFC42 I was able to identify the CString::FreeData() function at 0x5f402125, but winedbg tells me it's 0x5f445900. Is this a known problem? yes, when you have several versions of MFC42.PDB like you seem to do (we don't lookup up for the right one yet) A+ The thing is that I can't see that this is the case here. I have: [EMAIL PROTECTED] ~]$ find ~/.wine/drive_c/ -name "MFC*" -o -name "mfc*" /home/palm/.wine/drive_c/windows/system/MFC42.DLL /home/palm/.wine/drive_c/hager/Semiolog/Apps/MFC42.MAP /home/palm/.wine/drive_c/hager/Semiolog/Apps/MFC42.PDB I have copied those DLL's off a VC++ 6.0 CD: MFC42.DLL from OS\SYSTEM into windows/system MFC42.MAP + MFC42.PDB from VC98\DEBUG into the directory I run the application from. Still have the exact same problem... Regards, -- Christer Palm
winedbg symbols completely screwed
Continuing my debugging efforts, I decided to look some more at the strange symbols I got in the backtrace. Indeed, it seems like winedbg completely screws up the MFC42 symbols. For example, by disassembling from the load address of MFC42 I was able to identify the CString::FreeData() function at 0x5f402125, but winedbg tells me it's 0x5f445900. Is this a known problem? Regards, -- Christer Palm
Re: Debugging a null pointer dereference
Marcus Meissner wrote: On Sat, Jan 14, 2006 at 08:41:50PM +0100, Christer Palm wrote: After messing around with with the mfc42 runtime, I managed to get a backtrace with debugging information, which looks like this: =>1 0x5f4056dd CEnumOleVerb::~CEnumOleVerb+0x37 [oleverb.cpp:61] in mfc42 (0x5f4056dd) You should find out what it does before. Capture a WINEDEBUG=+relay,+seh trace (redirect output to a logfile). Then look at this trace, search for the winedbg call and scroll back until the RaiseException with c0005 code (likely only some dozen lines above the initial debugger start). The look backwards from this to see where it might have got this NULL pointer... :/ If its bad, it could have got it from millions of lines ago. :/ Hello Marcus and thanks for your response! OK, sounds a bit ad-hoc to me but I'm sure that you're talking from experience. In the relay trace, I can see that just before the exception is raised, it sits in a loop calling: 0009:Call user32.ShowWindow(,) ret=5f4056f5 0009:Ret user32.ShowWindow() retval= ret=5f4056f5 33 times (same return address each time), which looks a bit suspicious to me (HWND being 0). The return address is in MFC42, but as winedbg refuses to run the dang thing I can't resolve that into the actual MFC function or set any breakpoints or anything. So, looking a bit further up in the trace, my best bet is that it's getting that HWND from: 0009:Call user32.GetParent(00010026) ret=5f401281 ... 0009:Ret user32.GetParent() retval= ret=5f401281 But that's just a wild guess. 00010026 seems to the apps main window, because I see a lot of activity on that HWND before the crash - for example: 0009:Call user32.DrawMenuBar(00010026) ret=5f4136d0 ... 0009:Ret user32.DrawMenuBar() retval=0001 ret=5f4136d0 And I can see the menu bar of the main (top) window being updated just before the crash. I played around a bit with the graphics settings in winecfg with no result other than that I've now managed to lock myself out of wine (including winecfg) by specifying an invalid display depth :-( Does anyting of this make sense? Cheers, -- Christer Palm
Debugging a null pointer dereference
comctl32 \-PE 0x00d7-00e29000 \ comctl32 \-PE 0x00d7-00e29000 \ comctl32 \-PE 0x00d7-00e29000 \ comctl32 \-PE 0x00d7-00e29000 \ comctl32 ELF 0x00e67000-00ee5000 Deferredntdll \-PE 0x00e8-00ee5000 \ ntdll ELF 0x00ee5000-00f83000 Deferredoleaut32 \-PE 0x00f0-00f83000 \ oleaut32 ELF 0x00feb000-01073000 Deferredwinex11 \-PE 0x0100-01073000 \ winex11 ELF 0x068a4000-06916000 Deferredlibkrb5.so.3 ELF 0x06c2-06c25000 Deferredlibxxf86vm.so.1 PE 0x1000-1000b000 Deferredhcore PE 0x5f40-5f4f2000 Deferredmfc42 ELF 0x5fa38000-5fc15000 Deferredi915_dri.so ELF 0x7bf0-7bf03000 Deferred Threads: process tid prio (all id:s are in hex) 000a (D) C:\hager\Semiolog\Apps\Semiolog.exe 000b0 <== WineDbg terminated on pid 0xa wine client error:b: write: Bad file descriptor [100's of Bad file descriptor errors just like the one above] wine client error:b: err:seh:setup_exception stack overflow 292 bytes in thread 000b eip 0014bb0e esp 7fb80edc stack 0x7fb81000-0x7fc9 Any clues? Cheers, -- Christer Palm
