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

[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