World of Warcraft - crash in game

[Troy Rollo]

On Fri, 25 Feb 2005 09:22, Alex Woods wrote:
> Over the course of 13 (unlucky for me ;)) crashes, these are the only 3
> addresses it has given.  My question is what can I do to debug [target 
> application SEGVs]. 

I can't find any good explanation of this either. Googling for "gdb objdump 
site:winehq.org" gets nothing relevant, and "winedbg objdump" is no better, 
so it may be that nobody has written an explanation for it before.

This is something that requires a huge amount of patience. Expect to spend 
days (or longer) looking for individual errors. If you don't have that kind 
of patience, you may be better off not trying, but if you do, then this kind 
of thing can be very rewarding when you do succeed.

When debugging a SEGV that occurs in the target application, you need 
familiarity with a number of things.

1. The WINE Developer's Guide <http://www.winehq.com/docs/wine-devel.html>
2. GDB (or in this case, winedbg --gdb)
3. objdump.
4. Intel assembly language (in the AT&T style, not the Intel style, since the
  GNU disassembly code for Intel style output is broken for some addressing
  modes and has been for years).

Once you are familiar with these, the procedures for debugging an application 
SEGV are:

1. Get an assembly listing of the target program. You will need to refer to
    this while debugging.

 $ objdump --disassemble program.exe > program.asm

2. Make sure you have BreakOnFirstChance turned OFF. Windows
   applications often generate first chance exceptions routinely, and it's
   rarely helpful to stop the debugger for them. See section 1.5.2 of the
   WINE Developer's Guide to find out how to turn this off.

3. Start the application in GDB:

   a. The simple way:

  $ winedbg --gdb program.exe

   b. The better way when debugging a game is to run the debugger
       from another keyboard or monitor (such as from an ssh connection
       from another machine), the reason being games tend to do funny
       things to the display that may make it impractical to debug. In this
       case, you need to set the DISPLAY variable to make the game run
       on the X display. I generally use a laptop and ssh to the desktop:

 you at laptop $ ssh desktop
 Password:
 you at desktop $ cd .wine/c/gamedir
 you at desktop $ DISPLAY=:0 winedbg --gdb program.exe

4. Run the program until you generate the SEGV

 gdb> run

5. When you get the SEGV, you need to trace the source of the value that
    caused the problem. This will involve a number of things:

 a. Tracing values through register assignments and local variables.
     This is fairly straight-forward.

 b. Tracing values back through earlier function calls (usually requires
      setting a breakpoint, possibly a conditional one, in the caller).

 c. Tracing values set into global variables. Usually involves searching
     the assembly listing generated in step 1 and then putting break points
     on all the locations that set the variable.

 d. In some situations you will need to use GDB's watch points, but this
     can be very slow and should be used as a last resort.

   The aim here is to find some value returned from WINE that caused the
   value that caused the SEGV.