Created attachment 53876 [details] wine backtrace This assertion failure makes Killing Floor crash in wine. I had originally filed the bug in wine but they think it's a pulseaudio bug. Wine bug: http://bugs.winehq.org/show_bug.cgi?id=29187 Distro: Debian unstable I wasn't sure what component to file this against so I made my best guess based on the backtrace.
Do you see this in any applications other than Killing Floor? And what version of alsa-plugins and pulseaudio are you using?
I've only noticed it crash in Killing Floor. Package versions on Debian unstable: alsa-plugins: 1.0.24-3 pulseaudio: 1.1-2
The same crash also happens in Arch with a more up to date lib32-alsa-plugins (libpulsecommon-1.1 as opposed to 0.9.21)
Dota 2 also crashes with a pulse-related error. This is on Arch with lib32-alsa-plugins 1.0.24 and pulseaudio 1.1 Assertion 'b' failed at pulsecore/memblock.c:454, function pa_memblock_acquire(). Aborting. =>0 0xf77ab430 __kernel_vsyscall+0x10() in [vdso].so (0x1261e7dc) 1 0xf74b439f gsignal+0x4e() in libc.so.6 (0x1261e7dc) 2 0xf74b5d25 abort+0x174() in libc.so.6 (0x1261e7dc) 3 0x7c3c3059 pa_memblock_acquire+0x88() in libpulsecommon-1.1.so (0x1261e7dc) 4 0x7c48ebda pa_stream_peek+0x109() in libpulse.so.0 (0x1261e7dc) 5 0x7dcddd03 _init+0xac6() in libasound_module_pcm_pulse.so (0x1261e7f8) 6 0x78599421 in libasound.so.2 (+0x90420) (0x1261e838) 7 0x785566a7 in libasound.so.2 (+0x4d6a6) (0x1261e878) 8 0x7859965f in libasound.so.2 (+0x9065e) (0x1261e8e8) 9 0x7854ee04 snd_pcm_readi+0x53() in libasound.so.2 (0x1261e918)
Created attachment 56271 [details] output of pulseaudio -vvvvv
Also affects Star Trek Online
This assertion failure also affects Sid Meier's Railroads with wine-1.5.1 on up to date Ubuntu 11.10 32 bit.
A workaround that looks like it worked for me was in /etc/pulse/server.conf to set "enable-shm = no". That eliminated the crashes in Killing Floor. Star Trek Online was still crashing, but for reasons unrelated to this bug.
We've also managed to trigger the bug using a gstreamer pipeline in xpra: http://xpra.org/trac/ticket/288 Disabling shm does prevent the crash, but this should not be needed. As per the ticket above, this seems to occur when the client application disconnects from pulseaudio. Maybe pulseaudio cleans up the shm area too early, whilst the client (in our case a gstreamer pipeline) is reading the mmap region? (just a guess)
I believe this is fixed by this commit: http://cgit.freedesktop.org/pulseaudio/pulseaudio/commit/?id=dfd44036b54d65314664622ff93dfd18eee03c7b It's included in PulseAudio 3.0, so upgrading PulseAudio should get rid of the crash.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.