- Wine-Devel - list.winehq.org

Debugging with GDB [was: Re: World of Warcraft - crash in game]
by Alex Woods April 24, 2005

April 24, 2005

On Thu, Mar 03, 2005 at 08:13:41AM +1100, Troy Rollo wrote: > On Thu, 3 Mar 2005 03:43, Alex Woods wrote: > > Unfortunately, I never got to try out this method properly. WoW has > > it's own dbghelp.dll that it checks on login and that contains different > > functions to wine's dbghelp. So I got stuck there, but it's not all bad > > news. > > In that case you may be able to use GDB directly on the executable (without > winedbg) and attach after the app has started with > "gdb /usr/local/bin/wine-pthread process-id". The major drawback of this is > that it cannot tell the difference between a first chance exception and a > last chance exception, so if the app uses exception handling you may end up > using GDB's "pass" command a lot. Well, after a long break, I'm back at trying to debug wine + WoW again. Somewhere alsa stopped working for me totally in wine (multilib problem I think). Now that it's working again, running the winmm and dsound tests I don't get any crashes, which I did before. I still get crashes in WoW though, with both OSS and ALSA, so I figure I'll try to get to the bottom of the common problems first before going back to see if ALSA is still a problem. I'm attaching to the process with gdb, but it's not catching things at the point where they go wrong. Typically I am just seeing a stack like this though: #0 0x56752a01 in ?? () I might be doing something wrong. It's been a long time since I used gdb for anything threaded, and never with NTLM. I've tried attaching to wine-pthread process and the wine-preloader process, with pretty much the same results. It's a real shame that +relay slows things down too much for be to be able to get to the point where a crash occurs. Does anyone have any suggestions as to how I might get a handle on where things are going wrong? How are exceptions caught by wine? A lot of the time WoW handles the error so can I work back from there? A lot of the time I get a report like this: This application has encountered a critical error: Not enough memory Program: C:\Program Files\World of Warcraft\WoW.exe File: C:\build\buildWoW\WoW\Source\WorldClient\MapMem.cpp Line: 589 WoWBuild: 4341 ------------------------------------------------------------------------------ ---------------------------------------- Stack Trace (Manual) ---------------------------------------- Address Frame Logical addr Module 0064F43E 55C0F970 0001:0024E43E C:\Program Files\World of Warcraft\WoW.exe 006500A5 55C0F988 0001:0024F0A5 C:\Program Files\World of Warcraft\WoW.exe 00651464 55C0F9A8 0001:00250464 C:\Program Files\World of Warcraft\WoW.exe 006B9F82 55C0F9D0 0001:002B8F82 C:\Program Files\World of Warcraft\WoW.exe 006D8FC6 55C0FAF4 0001:002D7FC6 C:\Program Files\World of Warcraft\WoW.exe 006B16AE 55C0FB20 0001:002B06AE C:\Program Files\World of Warcraft\WoW.exe 006B13B7 55C0FB3C 0001:002B03B7 C:\Program Files\World of Warcraft\WoW.exe 00689769 55C0FB4C 0001:00288769 C:\Program Files\World of Warcraft\WoW.exe 0048E70F 55C0FC00 0001:0008D70F C:\Program Files\World of Warcraft\WoW.exe 0048E293 55C0FC8C 0001:0008D293 C:\Program Files\World of Warcraft\WoW.exe 0076DDE1 55C0FCB0 0001:0036CDE1 C:\Program Files\World of Warcraft\WoW.exe 00762520 55C0FCD8 0001:00361520 C:\Program Files\World of Warcraft\WoW.exe 00760C72 55C0FCE4 0001:0035FC72 C:\Program Files\World of Warcraft\WoW.exe 0044224E 55C0FDAC 0001:0004124E C:\Program Files\World of Warcraft\WoW.exe 0041B8E6 55C0FDE4 0001:0001A8E6 C:\Program Files\World of Warcraft\WoW.exe 004175EA 55C0FE5C 0001:000165EA C:\Program Files\World of Warcraft\WoW.exe 00416D71 55C0FE74 0001:00015D71 C:\Program Files\World of Warcraft\WoW.exe 004044B0 55C0FF14 0001:000034B0 C:\Program Files\World of Warcraft\WoW.exe 55A58B9B 55C0FFF4 0001:00057B9B c:\windows\system\kernel32.dll Am I right in thinking that the logical address is the address I should use to look up the point it's failing in kernel32.dll? Using that and an asm dump of kernel32.dll.so places it in the error section of FindFirstFileExW I think: 57b82: 00 57b83: 89 04 24 mov %eax,(%esp) 57b86: e8 91 80 00 00 call 5fc1c <HeapFree> 57b8b: 83 ec 0c sub $0xc,%esp 57b8e: 8d 45 e8 lea 0xffffffe8(%ebp),%eax 57b91: 89 04 24 mov %eax,(%esp) 57b94: e8 37 21 fe ff call 39cd0 <RtlFreeUnicodeString> 57b99: 83 ec 04 sub $0x4,%esp 57b9c: c7 45 b0 ff ff ff ff movl $0xffffffff,0xffffffb0(%ebp) 57ba3: 8b 45 b0 mov 0xffffffb0(%ebp),%eax 57ba6: 8b 5d fc mov 0xfffffffc(%ebp),%ebx 57ba9: c9 leave 57baa: c2 18 00 ret $0x18 If I attach to wine-pthread and stick a breakpoint in that function, it does indeed get called right before WoW crashes out with the Out of memory error. I guess I'll work that back, seeing as I it's something I've found out during the course of writing this email, but any suggestions as to how I can make debugging easier would be truly appreciated, as would any answers to my questions. Cheers. -- Alex

2 2

Re: Installing Mozilla
by Juan Lang April 24, 2005

April 24, 2005

Alex wrote: > I'm encountering a crash when trying to install Mozilla 1.7.7 under > wine. I am using a fresh CVS checkout, but I've tried older revisions > with the same result. So far, this evidence points to a bug in Mozilla rather than in Wine. It may very well be triggered by a bug in Wine.. > Here is a backtrace. It's falling over trying to write to > 0x99806858. Mozilla's passing an apparently invalid pointer to WideCharToMultiByte. Question is, where does this come from? Running with WINEDEBUG=nls may give a clue what string it's trying to convert, which may give some indication of the problem. Running with WINEDEBUG=relay will probably give a better clue, but be prepared for a huge log. But since the Mozilla source is available, you may be able to hunt it down more easily using that. --Juan __________________________________ Do you Yahoo!? Yahoo! Small Business - Try our new resources site! http://smallbusiness.yahoo.com/resources/

4 3

Odd problem with process handles
by Robert Lunnon April 24, 2005

April 24, 2005

I am having a problem with the attached segfault in ie6 I have attached a gdb backtrace and the last part of a relay dump. hModule is 0xffffffffe and gets dereferenced to find e_magic presumably from the psp. Obviously dereferencing 0xfffffffe is not good which raises an exception The exception is caught and appears to be ignored the first time it occurs but this seems unusual to me Can anyone shed light on this, is this normal or do I have a problem. What's going on here ? More info follows Bob ============================================================================ Starting program: /opt/cfw/wine/bin/wine iexplore Program received signal SIGSEGV, Segmentation fault. 0xd1cbfb5f in RtlImageNtHeader (hModule=0xfffffffe) at loader.c:1907 1907 if (dos->e_magic == IMAGE_DOS_SIGNATURE) (gdb) print dos $1 = (IMAGE_DOS_HEADER *) 0xfffffffe *** Aparrently in this code 1895 /*********************************************************************** 1896 * RtlImageNtHeader (NTDLL.@) 1897 */ 1898 PIMAGE_NT_HEADERS WINAPI RtlImageNtHeader(HMODULE hModule) 1899 { 1900 IMAGE_NT_HEADERS *ret; 1901 1902 __TRY 1903 { 1904 IMAGE_DOS_HEADER *dos = (IMAGE_DOS_HEADER *)hModule; (gdb) 1905 1906 ret = NULL; 1907 if (dos->e_magic == IMAGE_DOS_SIGNATURE) 1908 { 1909 ret = (IMAGE_NT_HEADERS *)((char *)dos + dos->e_lfanew); 1910 if (ret->Signature != IMAGE_NT_SIGNATURE) ret = NULL; 1911 } 1912 } 1913 __EXCEPT(page_fault) 1914 { (gdb) 1915 return NULL; 1916 } 1917 __ENDTRY 1918 return ret; 1919 } **** Relay output 00b:Ret kernel32.LoadLibraryA() retval=00000000 ret=70c2429c 000b:Call kernel32.GetLastError() ret=70c242a9 000b:Ret kernel32.GetLastError() retval=0000007e ret=70c242a9 000b:Call kernel32.InterlockedExchange(70c2bd84,ffffffff) ret=70c242f0 000b:Ret kernel32.InterlockedExchange() retval=00000000 ret=70c242f0 000b:Call kernel32.GetProcAddress(ffffffff,70c24832 "ApphelpCheckShellObject") ret=70c24399 000b:Call ntdll.RtlInitAnsiString(7fd8dc18,70c24832 "ApphelpCheckShellObject") ret=7fe1e655 000b:Ret ntdll.RtlInitAnsiString() retval=7fd80018 ret=7fe1e655 000b:Call ntdll.LdrGetProcedureAddress(ffffffff,7fd8dc18,00000000,7fd8dc20) ret=7fe1e667 **** GDB Backtrace (gdb) bt #0 0xd1cbfb5f in RtlImageNtHeader (hModule=0xfffffffe) at loader.c:1907 #1 0xd1cc0018 in RtlImageDirectoryEntryToData (module=0xfffffffe, image=0, dir=0, size=0x7fd8db3c) at loader.c:2025 #2 0xd1cbdcd1 in LdrGetProcedureAddress (module=0xffffffff, name=0x7fd8dc18, ord=0, address=0x7fd8dc20) at loader.c:1154 #3 0xd1ccabcf in call_stdcall_function (func=0xd1cbdc9b <LdrGetProcedureAddress>, nb_args=4, args=0x7fd8dc08) at relay.c:521 #4 0xd1ccb2e0 in RELAY_CallFrom32 (ret_addr=2145511015) at relay.c:603 #5 0xd1d00025 in __wine_spec_exp_ordinals () from /opt/cfw/wine/lib/wine/ntdll.dll.so #6 0xd1ccab7d in call_stdcall_function (func=0x7fe1e62b <GetProcAddress>, nb_args=2, args=0x7fd8dce4) at relay.c:519 #7 0xd1ccb2e0 in RELAY_CallFrom32 (ret_addr=1891779481) at relay.c:603 #8 0x7fec08dd in __wine_spec_forwards () from /opt/cfw/wine/lib/wine/kernel32.dll.so #9 0x70c23bd1 in ?? () #10 0x71191420 in ?? () #11 0x711819aa in ?? () #12 0x7118a3c9 in ?? () #13 0x71165a1c in ?? () #14 0x7fbab1af in WINPROC_wrapper () from /opt/cfw/wine/lib/wine/user32.dll.so #15 0x7fbab61d in WINPROC_CallWndProc (proc=0x71165af5, hwnd=0x20022, msg=129, wParam=0, lParam=2144920548) at ../../windows/winproc.c:418 #16 0x7fbb21a6 in CallWindowProcA (func=0x71165af5, hwnd=0x20022, msg=129, wParam=0, lParam=2144920548) at ../../windows/winproc.c:3202 #17 0x7fbea1f4 in call_window_proc (hwnd=0x20022, msg=129, wparam=0, lparam=2144920548, unicode=0, same_thread=1) at message.c:1521 #18 0x7fbec0cb in SendMessageTimeoutA (hwnd=0x20022, msg=129, wparam=0, lparam=2144920548, flags=0, timeout=4294967295, res_ptr=0x7fd8df78) at message.c:2376 #19 0x7fbec299 in SendMessageA (hwnd=0x20022, msg=129, wparam=0, lparam=2144920548) at message.c:2420 #20 0xd1ccabcf in call_stdcall_function (func=0x7fbec266 <SendMessageA>, nb_args=4, args=0x7fd8e040) at relay.c:521 #21 0xd1ccb2e0 in RELAY_CallFrom32 (ret_addr=2137925787) at relay.c:603 #22 0x7fc3e3a1 in __wine_spec_exp_ordinals () from /opt/cfw/wine/lib/wine/user32.dll.so #23 0xd1cca480 in call_cdecl_function (func=0x7f6e23b6 <X11DRV_CreateWindow>, nb_args=3, args=0x7fd8e1c0) at relay.c:462 #24 0xd1ccb2c2 in RELAY_CallFrom32 (ret_addr=2142912231) at relay.c:599 #25 0x7f71a3a1 in __wine_spec_exp_ordinals () from /opt/cfw/wine/lib/wine/x11drv.dll.so #26 0x7fba4554 in CreateWindowExA (exStyle=256, className=0x7fd8e538 "IEFrame", windowName=0x7fd8e74c "Microsoft Internet Explorer", style=47120384, x=-2147483648, y=-2147483648, width=-2147483648, height=-2147483648, parent=0x0, menu=0x94, instance=0x71160000, data=0x7ff39fb8) at ../../windows/win.c:1245 #27 0xd1ccae57 in call_stdcall_function (func=0x7fba43da <CreateWindowExA>, nb_args=12, args=0x7fd8e4fc) at relay.c:535 #28 0xd1ccb2e0 in RELAY_CallFrom32 (ret_addr=1891617362) at relay.c:603 #29 0x7fc3c851 in __wine_spec_exp_ordinals () from /opt/cfw/wine/lib/wine/user32.dll.so #30 0x71181c0e in ?? () #31 0x71181acf in ?? () #32 0x71181a86 in ?? () #33 0x7101f031 in ?? () #34 0x00401ecd in ?? () #35 0x00401f7d in ?? () #36 0x7fe2cbf2 in start_process (arg=0x0) at process.c:1044

2 1

Re: Odd problem with process handles
by Juan Lang April 24, 2005

April 24, 2005

Hi Bob, > hModule is 0xffffffffe and gets dereferenced to find e_magic > presumably from the psp. Could you try the following really quick patch? I have no idea where the -1 value to GetProcAddress comes from, LoadLibraryA returned NULL. I'm also not sure whether the check belongs in here or in GetProcAddress. But this might let it get further for you. Index: dlls/ntdll/loader.c =================================================================== RCS file: /home/wine/wine/dlls/ntdll/loader.c,v retrieving revision 1.87 diff -u -r1.87 loader.c --- dlls/ntdll/loader.c 21 Mar 2005 10:52:26 -0000 1.87 +++ dlls/ntdll/loader.c 24 Apr 2005 17:09:39 -0000 @@ -2017,6 +2017,8 @@ const IMAGE_NT_HEADERS *nt; DWORD addr; + if ( module == (HMODULE)-1 ) + return NULL; if ((ULONG_PTR)module & 1) /* mapped as data file */ { module = (HMODULE)((ULONG_PTR)module & ~1); __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

1 0

More problems in ie6
by Robert Lunnon April 24, 2005

April 24, 2005

In addition to the bad process handle I get intermittent crashes in IE6 which seems to be due to the creation of more than 8 threads or when a thread is ended (IE it occurs after thread 8 starts, then exits then another thread 8 starts (9th thread creation)) Thread 8 is the first thread that actually exited in the program. Are there any resource limits to per process thread creation in wine ? This seems to lead to a crash in temp_stacks +111 but temp stacks should not hold any executable code. The web site that seems to tickle this problem is www.gamedude.com.au Any Guesses anyone ? Bob

1 0

Copy Protection
by Dustin Navea April 24, 2005

April 24, 2005

Guys, bug 2895 got me thinkin.. If we only support a handful of games that use copy protection, shouldnt we file a bug in Bugzilla and append that to 1434 (Get games working perfectly)? That way we can attach any copy protection related bugs to this metabug? If you are agreeable to to that, I will go ahead and file it. Dustin

2 1

Re: Some fixes for filtergraph.c
by Christian Costa April 24, 2005

April 24, 2005

Hi Maarten, Maarten Lankhorst wrote: > This doesn't fix everything, just theroutines i called.. some other > similar functions aren't fixed because filtergraph.c is really THAT > leaky..b mostly with reference counts.. Yes, Indeed. :-) Here are some comments : > >------------------------------------------------------------------------ > >--- wine-20050310/dlls/quartz/filtergraph.c 2005-03-02 11:12:12.000000000 +0100 >+++ wine/dlls/quartz/filtergraph.c 2005-04-24 00:50:30.000000000 +0200 >@@ -556,8 +556,7 @@ > IPin_QueryDirection(ppin, &pindir); > if (pindir == PINDIR_OUTPUT) > i++; >- else >- IPin_Release(ppin); >+ IPin_Release(ppin); > } > *pppins = CoTaskMemAlloc(sizeof(IPin*)*i); > /* Retrieve output pins */ >@@ -650,6 +649,7 @@ > IPin** ppins; > IPin* ppinfilter; > IBaseFilter* pfilter = NULL; >+ BOOL HaveEnumPin = FALSE; > > Why don't you just set ppinfilter to NULL and do "if (ppinfilter) IPin_Release(ppinfilter);" at the end ? > hr = GetFilterInfo(pMoniker, &clsid, &var); > IMoniker_Release(pMoniker); >@@ -677,6 +677,7 @@ > ERR("Enumpins (%lx)\n", hr); > goto error; > } >+ > hr = IEnumPins_Next(penumpins, 1, &ppinfilter, &pin); > if (FAILED(hr)) { > ERR("Next (%lx)\n", hr); >@@ -687,6 +688,7 @@ > goto error; > } > IEnumPins_Release(penumpins); >+ HaveEnumPin = TRUE; > > See above. > hr = IPin_Connect(ppinOut, ppinfilter, NULL); > if (FAILED(hr)) { >@@ -703,17 +705,21 @@ > TRACE("pins to consider: %ld\n", nb); > for(i = 0; i < nb; i++) { > TRACE("Processing pin %d\n", i); >- hr = IGraphBuilder_Connect(iface, ppins[0], ppinIn); >+ hr = IGraphBuilder_Connect(iface, ppins[i], ppinIn); > if (FAILED(hr)) { >- TRACE("Cannot render pin %p (%lx)\n", ppinfilter, hr); >- return hr; >+ TRACE("Cannot render pin %p (%lx)\n", ppinfilter, hr); > } >+ IPin_Release(ppins[i]); >+ if (SUCCEEDED(hr)) break; > This is not correct, you must connect all pins, not just the first that succeeds. > } > CoTaskMemFree(ppins); >+ IBaseFilter_Release(pfilter); >+ IPin_Release(ppinfilter); >+ break; > } >- break; > > error: >+ if (HaveEnumPin) IPin_Release(ppinfilter); > See above. > if (pfilter) { > IGraphBuilder_RemoveFilter(iface, pfilter); > IBaseFilter_Release(pfilter); >@@ -1175,13 +1181,16 @@ > ULONG nb; > ULONG i; > PIN_INFO PinInfo; >+ BOOL HavePinInfo = FALSE; > > TRACE("%p %p %lld\n", pGraph, pOutputPin, tStart); > > hr = IPin_ConnectedTo(pOutputPin, &pInputPin); > >- if (SUCCEEDED(hr)) >+ if (SUCCEEDED(hr)) { >+ HavePinInfo = TRUE; > hr = IPin_QueryPinInfo(pInputPin, &PinInfo); >+ } > > Personally, I would set PinIno.pFilter to NULL on failure and do if (PinIno.pFilter) release... at the end. But it's just a matter of taste. > if (SUCCEEDED(hr)) > hr = GetInternalConnections(PinInfo.pFilter, pInputPin, &ppPins, &nb); >@@ -1202,6 +1211,7 @@ > * FIXME: We should prevent exploring from a pin more than once. This can happens when > * several input pins are connected to the same output (a MUX for instance). */ > ExploreGraph(pGraph, ppPins[i], tStart); >+ IPin_Release(ppPins[i]); > } > > CoTaskMemFree(ppPins); >@@ -1210,6 +1220,7 @@ > IBaseFilter_Run(PinInfo.pFilter, tStart); > } > >+ if (HavePinInfo) IBaseFilter_Release(PinInfo.pFilter); > return hr; > } > >@@ -1255,9 +1266,11 @@ > IPin_QueryDirection(pPin, &dir); > if (dir == PINDIR_INPUT) > { >+ IPin_Release(pPin); > source = FALSE; > break; > } >+ IPin_Release(pPin); > That would be simplier to do a single call to IPinRelease after IPin_QueryDirection. > } > if (source == TRUE) > { >@@ -1267,6 +1280,7 @@ > { > /* Explore the graph downstream from this pin */ > ExploreGraph(This, pPin, 0); >+ IPin_Release(pPin); > } > IBaseFilter_Run(pfilter, 0); > } > > Nice patch, BTW! :-) Bye, Christian

1 0

Re: WoW, er Wine on Windows--Re: Still more fun?
by Steven Edwards April 24, 2005

April 24, 2005

--- Augustus Saunders <augustus.saunders(a)verilogix.net> wrote: > I appreciate any feedback anybody has. Thanks- It wont work for DirectX. Wine directX structures and implementation is incompatible with Windows currently. Normal Win32 dlls work fine. Thanks Steven __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

1 0

Re: [AppDB] Version 1.00 of Warcraft III added by Christopher Morgan
by Jesse Allen April 23, 2005

April 23, 2005

On 4/23/05, AppDB <appdb(a)winehq.org> wrote: > > Version 1.00 of Warcraft III added by Christopher Morgan > ------------------------------------------------------- > http://appdb.winehq.org/appview.php?versionId=3051 > This version has been submitted by Ben Klein. > > Best regards. > The AppDB team > http://www.winehq.org/ > > If you don't want to receive any other e-mail, please change your preferences: > http://appdb.winehq.org/preferences.php > > Hmmm. Should we be avoiding duplicate information? I already maintain a howto listed under "1.00+". In it I already cover, one running the game, including NoCD patches (though I encourage running official exe's and show how it's done) and second the issues with game movies. What this new note does not cover is running under opengl, working multiplayer and battle.net modes, winver settings to use, differentiation of wine versions, and miscellenous bugs. This new note may be a little misleading because Warcraft 3 uses D3D8 so Oliver's patch is not required, but it may be an improvement, I don't know. I typically run the game in opengl. There are other instances of duplicate information in the Appdb, perhaps we need to clean this up. But it is enormous work. I have a hard time just keeping my howto up to date. Jesse

2 1

Re: Installing Mozilla
by Juan Lang April 23, 2005

April 23, 2005

--- James Hawkins <truiken(a)gmail.com> wrote: > Just because Mozilla is passing a bad memory address doesn't mean > it's a bug in Mozilla. For example Mozilla could have requested > some information from wine and we gave them the bad memory address. While that's certainly possible in general, that doesn't appear to be the case here. The bad pointer is the destination address of WideCharToMultiByte, not the source. Typically this will some buffer or other internal to Mozilla. I'm not claiming there isn't a bug in Wine. But I think the immediate thing we're seeing is a bug in Mozilla (likely triggered by a bug in Wine.) The nls trace might be interesting, because the source pointer appears to be valid. So, what string are they trying to translate? An error message perhaps? That might point to the cause of the problem. --Juan __________________________________ Do you Yahoo!? Yahoo! Small Business - Try our new resources site! http://smallbusiness.yahoo.com/resources/

4 6