Hi,
World of Warcraft is working beautifully now apart from a crash that occurs seemingly randomly. The application is catching the crash, and giving a message like this:
This application has encountered a critical error:
ERROR #132 (0x85100084) Program: C:\Program Files\World of Warcraft\WoW.exe Exception: 0xC0000005 (ACCESS_VIOLATION) at 0023:557102CD
EAX=00000000 EBX=55BDFCA8 ECX=00000000 EDX=55BDFBB8 ESI=5E320308 EDI=00000000 EBP=55BDFC08 ESP=55BDFB9C EIP=557102CD FLG=00010212 CS =0023 DS =002B ES =002B SS =002B FS =005B GS=0063
I know this isn't really much use on it's own. I've tried turning on +relay logging, but it's proved futile - it seems to end up freezing up my system before a crash occurs. One thing that might be useful is that the access violation always seems to be around the same small area of memory each time, eg:
Exception: 0xC0000005 (ACCESS_VIOLATION) at 0023:557103CD Exception: 0xC0000005 (ACCESS_VIOLATION) at 0023:5571025D
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 this? +relay logging is probably infeasible, but I'd be happy to hack around to get it to only log certain things - I'm not sure what I'd need to log. Also, the last time it crashed, I was lucky enough to have it leave me in winedbg, which I've left open. Is there anything worth my while poking around with in there while I have the chance?
I guess I'll be running memtest on my machine too, but I'd like to do what I can in winedbg first ;)
Cheers.
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.
On Fri, Feb 25, 2005 at 11:07:03AM +1100, Troy Rollo wrote:
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.
Unfortunately, I never got to try out this method properly. WoW has it's own dbghelp.dll that it checks on login and that contains different functions to wine's dbghelp. So I got stuck there, but it's not all bad news.
Whilst playing around trying to get some kind of lead, the sound cut out on me whilst playing the game. I decided to keep going, and the game played for a surprisingly long time. The next day I booted the game with wine's sound drivers disabled and played for about 10 hours total without a crash (for purely stress-test reasons you understand ;)). I've had a chance to give it a go with the wineoss.drv.so now and that also seems stable, so I guess the problem is in winealsa.drv.so which I had been using.
I haven't had a chance to try to get some debug logs just for the sound yet, but when I get the time I will.
Cheers.
Hey,
On Wed, 2 Mar 2005 16:43:11 +0000, Alex Woods wine-devel@giblets.org wrote:
Whilst playing around trying to get some kind of lead, the sound cut out on me whilst playing the game. I decided to keep going, and the game played for a surprisingly long time. The next day I booted the game with wine's sound drivers disabled and played for about 10 hours total without a crash (for purely stress-test reasons you understand ;)). I've had a chance to give it a go with the wineoss.drv.so now and that also seems stable, so I guess the problem is in winealsa.drv.so which I had been using.
I can confirm that. I only managed to get sound working to an acceptable rate (ticking, and stutters) with winealsa, no dmix/asym (I use that for my no harware mixing soundcard) and dsound hardware emulation. I will get a lot of these: fixme:dsound:DSOUND_MixOne problem with underrun detection (mixlen=32768 < primary_done=40572) err:dsound:DSOUND_MixOne underrun on sound buffer 0x404071d8
And: ALSA lib pcm_hw.c:590:(snd_pcm_hw_pause) SNDRV_PCM_IOCTL_PAUSE failed: Function not implemented err:wave:wodPlayer_ProcessMessages pcm_pause failed: Function not implemented
This last error is probably because of my usb ALSA driver for my usb headset.
Without dsound hardware emulation (so plain ALSA) I will get stuttering sound. And with wineoss (so, alsa oss emulation) I will not get any sound at all.
This is with a 2.6.9 kernel and alsa-driver 1.0.8.
Thanks, Paul
On Wed, Mar 02, 2005 at 06:52:36PM +0100, Paul van Schayck wrote:
Hey,
On Wed, 2 Mar 2005 16:43:11 +0000, Alex Woods wine-devel@giblets.org wrote:
Whilst playing around trying to get some kind of lead, the sound cut out on me whilst playing the game. I decided to keep going, and the game played for a surprisingly long time. The next day I booted the game with wine's sound drivers disabled and played for about 10 hours total without a crash (for purely stress-test reasons you understand ;)). I've had a chance to give it a go with the wineoss.drv.so now and that also seems stable, so I guess the problem is in winealsa.drv.so which I had been using.
I can confirm that. I only managed to get sound working to an acceptable rate (ticking, and stutters) with winealsa, no dmix/asym (I use that for my no harware mixing soundcard) and dsound hardware emulation. I will get a lot of these: fixme:dsound:DSOUND_MixOne problem with underrun detection (mixlen=32768 < primary_done=40572) err:dsound:DSOUND_MixOne underrun on sound buffer 0x404071d8
I get a lot of these too, with both winealsa and wineoss, but the rate seems very acceptable to me with not many ticks and stutters. I think also it got better in the last few days, and I notice that a few dsound changes were made, but I might be imagining things. I assume the dsound stuff is cpu bound.
Without dsound hardware emulation (so plain ALSA) I will get stuttering sound. And with wineoss (so, alsa oss emulation) I will not get any sound at all.
I just use whatever wine defaults to in that respect. I have a minimal config file:
WINE REGISTRY Version 2 [version] "windows"="winxp" [WinMM] "Drivers"="wineoss.drv" [x11drv] "DXGrab"="Y"
Sound works about the same under both alsa and oss (again alsa oss emulation). It's strange that you get no sound from oss. The only visible difference between the drivers from a user level for me is that alsa makes the game unstable whereas oss does not.
This is with a 2.6.9 kernel and alsa-driver 1.0.8.
Similar here, alsa driver is whatever version 2.6.9 comes with, but the libraries are 1.0.7.
On Wed, 2 Mar 2005, Alex Woods wrote: [...]
Sound works about the same under both alsa and oss (again alsa oss emulation). It's strange that you get no sound from oss.
Sound depends a lot on the sound card. Some sound cards support only specific sampling rates while others are more accomodating. And that's just one issue, at least on the wineoss side there are a lot of other issues such as mmap support, full duplex support and DSP_GETOSPACE support that vary from one sound card to the next (and to some extent from one Alsa configuration / OSS emulation version to the next) and which all cause trouble.
<rant>
And Wine is way too sensible to these issues, even more so if the application uses DirectSound. Part of this is because the Windows API is painful to emulate, but part of it is lack of debugging of basic sound. Unfortunately, debugging supposes one has a sound configuration that does not work which makes it even trickier.
What this means is that each Wine developer who has sound problems can essentially only count on himself to debug them. To do so I would recommend first checking that winmm works fine:
cd dlls/winmm/tests make test
and if the above works, do:
WINETEST_INTERACTIVE=1 ../../../tools/runtest -P wine -M winmm.dll -T ../../.. -p winmm_test.exe.so wave.c
And if the winmm tests worked fine, then do the DirectSound tests:
cd dlls/dsound/tests make test
already you may have to manually edit the Wine configuration file to set HardwareAcceleration = Emulation. That's an heresy, it should be automatic. Anyway once you get the above test going, do:
WINETEST_INTERACTIVE=1 ../../../tools/runtest -P wine -M dsound.dll -T ../../.. -p dsound_test.exe.so dsound.c
I know for a fact that many Wine users are having problems with basic not-low-latency stereo sound and unfortunately I have not seen any progress on this in the past couple of years (i.e. there are still about has many users having problems now as two years ago).
</rant>
On Thu, 3 Mar 2005 03:43, Alex Woods wrote:
Unfortunately, I never got to try out this method properly. WoW has it's own dbghelp.dll that it checks on login and that contains different functions to wine's dbghelp. So I got stuck there, but it's not all bad news.
In that case you may be able to use GDB directly on the executable (without winedbg) and attach after the app has started with "gdb /usr/local/bin/wine-pthread process-id". The major drawback of this is that it cannot tell the difference between a first chance exception and a last chance exception, so if the app uses exception handling you may end up using GDB's "pass" command a lot.
-
Alex Woods -
Francois Gouget -
Paul van Schayck -
Troy Rollo