Client - Windows Xpra 0.8.7 Server - Fedora 18 xpra-0.9.0-3.fc18.x86_64
Xpra crashes with this message
Assertion 'b' failed at pulsecore/memblock.c:454, function pa_memblock_acquire(). Aborting.
Stack trace
#0 0x00007f24660d8ba5 in raise () from /lib64/libc.so.6 #1 0x00007f24660da358 in abort () from /lib64/libc.so.6 #2 0x00007f2444a392cb in pa_memblock_acquire () from /usr/lib64/pulseaudio/libpulsecommon-2.1.so #3 0x00007f2444ea5e43 in pa_stream_peek () from /lib64/libpulse.so.0 #4 0x00007f2445531e34 in gst_pulsesrc_read () from /usr/lib64/gstreamer-0.10/libgstpulse.so #5 0x00007f244530d9d8 in audioringbuffer_thread_func () from /lib64/libgstaudio-0.10.so.0 #6 0x00007f245af3c605 in g_thread_proxy () from /lib64/libglib-2.0.so.0 #7 0x00007f2466b6ad15 in start_thread () from /lib64/libpthread.so.0 #8 0x00007f246619546d in clone () from /lib64/libc.so.6
Steps to reproduce
Start xpra server with
dbus-launch xpra --no-daemon --bind-tcp=0.0.0.0:1200 --start-child=xterm start :11
Connect to server and in xterm run chromium-browser
chromium-browser &
Xpra usually crashes at this point.
Ok, this comes from the gstreamer source pipeline which is reading sound data from the pa server (gst_pulsesrc_read
).
The stacktrace points to this PulseAudio bug.
Is this a regression? (I doubt it - made easier to fire, possibly). And if so, which was the last version which did not have this problem? Does disabling shm fix this? (tweak the pulseaudio_command option - it probably does, but we don't want to do that for performance reasons, just as a data point) Alternatively, there isn't much we can do.. apart from waiting for this bug to be fixed.
Please also try to run the xpra/sound/src.py tool from the command line on the same server system, but without xpra, and reproducing the steps (fire browser onwards). This is the exact same code that xpra uses, so it should crash in the same way (..should.. but since xpra does a lot more stuff, and this looks like a threading/race issue, it may not..) Do do this, you will have to run dbus and pulseaudio before launching the browser. Using a full desktop environment is one way, but a better approach is to do by hand to keep it minimal and closer to the way xpra does it. (far less easy though, so maybe try the full DE first)
The version I haven't been able to reproduce this is
xpra-0.8.8-1.fc18.x86_64
I disabled shm by editing /etc/pulse/daemon.conf
I can't seem to reproduce it now but I'll keep trying
Can test running src.py by itself but I will have to do that from a VM with a full DE will that suffice for that test?
Oh, so I guess we could bisect the code between 0.8.x and 0.9.x to see when things broke (there weren't many sound changes at all in 0.9.x which will make things much easier). My money is on: r2830 or r2833+r2834+r2835 (they go together)
Does removing this code from src.py
make any difference:
, "audio/x-raw-int,rate=44100,channels=2"
You're using the mp3 codec, right? Does switching codec make any difference?
The shm fix does point to the pulseaudio bug, which makes me think that even if we do find the problematic commit in xpra, there is no guarantee that we are doing anything wrong... Maybe we just make it more likely to bite.
Feel free to test src.py from a full DE, it shouldn't take too long that way.
I installed fedora 18 LXDE under virtualbox and confirmed the audio worked.
I ran src.py on its own and wasn't able to make it crash by doing the same things on this virtual machine.
After install xpra from a binary rpm package I would run
python /usr/lib/python2.7/site-packages/xpra/sound/src/.py ~/test.mp3 mp3
Then proceed to do the same steps I took to crash it through xpra.
I also tested to make sure it was working by playing the mp3 on the virtual machine with mpg123
mpg123 ~/test.mp3
And the sound was all correct. I guess this doesn't make it any more clear where it is crashing but this is what I have discovered.
Please also try with
AUDIORESAMPLE = True
In trunk xpra/sound/src.py
, this reverts the code to something closer to what is in the 0.8.x
branch.
Does this help? (if so, we may need a small queue element in there to shield us from whatever is going on in pulse_src
- though this should not really be needed and may only paper over the issue).
Also, does this happen with chromium only or also with google-chrome? Please clarify what the difference is between this ticket and the setup in comment:4, one works and the other one does not? (the DE is different but the packages should be the same and the Xpra server does not use any DE specific components at all) If that's the case, I guess you could try making them converge until you find what the difference is?
I'm not sure what the issue was but i'm unable to reproduce this in the current version 0.9.0beta.
I've enabled shared memory support for pulseaudio again and haven't had any issues.
I'll close this for now and reopen if the probably shows up again.
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/288