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.