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.
On Saturday 23 April 2005 22:12, Alex Woods wrote:
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 ?? ()
If it's only giving one frame in the stack trace the cause is normally a corrupted stack, so you may need to examine the stack to try to figure out where the stack frame should be (starting with "x/256xw" may be helpful if the stack pointer is still valid).
Otherwise, when debugging with GDB without going through winedbg you may need to use the "pass" command to skip over first chance exceptions in some cases before you get to the real exception.
On Sun, Apr 24, 2005 at 09:23:22AM +1000, Troy Rollo wrote:
On Saturday 23 April 2005 22:12, Alex Woods wrote:
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 ?? ()
If it's only giving one frame in the stack trace the cause is normally a corrupted stack, so you may need to examine the stack to try to figure out where the stack frame should be (starting with "x/256xw" may be helpful if the stack pointer is still valid).
Yeah, the stack always looks in pretty bad shape. The address of the #0 frame has been within nvidia's libGLCore.so.1 everytime I've had a SIGSEGV. Other times when an exception is caught by WoW, it often comes back with an Out of memory message from one of it's files - off the top of my head MapMem.cpp, SFile.cpp and Texture.cpp. I don't think it's a problem with the nvidia driver since it handles doom3 just fine. I do think it's a problem around the OpenGL space though, because turning down the graphical options makes the game stable. I might try playing with the options to see if any particular one is the cause.
Otherwise, when debugging with GDB without going through winedbg you may need to use the "pass" command to skip over first chance exceptions in some cases before you get to the real exception.
I'm not sure I'm seeing the first chance exceptions at all until - I presume these are exceptions that are raised but are expected to some extent and so are handled without stopping execution? I just seem to be seeing signals telling the thread it's been suspended I think. I'm not clear on how wine handles exceptions though.
Cheers.
-
Alex Woods -
Troy Rollo