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