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@laptop $ ssh desktop Password: you@desktop $ cd .wine/c/gamedir you@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.