Playing long sounds makes programs crash

Fredrik Tolf
Sat, 31 Aug 2002 18:03:54 -0000

It would seem that all programs that play sounds longer than about one
half second crash. They do not necessarily crash every time they do
this, but there is rather a fifty-fifty chance that they will crash for
every such sound they play. If they get past the first second of the
sound, however, that sound will not make the program crash. From what I
know of Win32, the program seems to be crashing from its own memory
space. At least according to gdb, the program got a SIGSEGV at
0x0040adc5 for the setup.exe on the starcraft cd-rom. That's in the
program's own space, isn't it? Anyways, every time the program crashes
like this, the debugger wrapper also crashes at address 0x400e3ef2,
which is on the following line:

strcpy( format, "winedbg --debugmsg -all --auto %ld %ld" );

This line as at line 256 in win32/except.c in my distribution. The last
output from wine is:
wine: Unhandled exception, starting debugger...
err:seh:EXC_DefaultHandling Unhandled exception code c0000005 flags 0
addr 0x400e3ef2
It isn't just starcraft's setup.exe that does this. sndrec32.exe also
exhibits this behavior, making me guess that it is the act of playing
the sound which is the root of the crash. Short sounds, however, such as
the sound when you highlight another menu item in starcraft's setup.exe,
never crashes the program. This leads me to believe that the program
crashes when it must refill the sound buffer, or something like that. I
don't really know how the windows sound API works.

My [WinMM] config looks like this:
"Drivers" = "wineoss.drv"
"WaveMapper" = "msacm.drv"
"MidiMapper" = "midimap.drv"

I am running kernel 2.4.19 and using glibc-2.2.4-24
This has happened before, too, with an older wine distrib (still from
2002, though), at which time I was using kernel 2.4.2 and glibc-2.2.2,
so it shouldn't be related to them. I haven't tried it using ALSA, but
that's because I'm not going to use ALSA, since it breaks my DVD player.
My sound card is a SB-Live, and therefore I am using the emu10k1 OSS
driver that came with my kernel.

Does someone know what's wrong and/or how to fix it?