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.