Debugging with GDB [was: Re: World of Warcraft - crash in game]
Alex Woods
wine-devel at giblets.org
Sun Apr 24 14:26:06 CDT 2005
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
More information about the wine-devel
mailing list