Debugging with GDB [was: Re: World of Warcraft - crash in game]

[Alex Woods]

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