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

[Troy Rollo]

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.

[Alex Woods]

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