Xpra: Ticket #1267: sound issues with CentOS 7.1.1503 - gstreamer1

When trying to connect a CentOS 7 client to an xpra server I get this traceback filling the screen when using sound

Traceback (most recent call last):
  File "/usr/lib64/python2.7/site-packages/gi/overrides/GLib.py", line 629, in <lambda>
    return (lambda data: callback(*data), user_data)
  File "/usr/lib64/python2.7/site-packages/xpra/sound/sink.py", line 283, in add_data
    buf = gst.new_buffer(data)
  File "/usr/lib64/python2.7/site-packages/xpra/sound/gstreamer_util.py", line 234, in new_buffer
    buf.fill(0, data)
  File "/usr/lib64/python2.7/site-packages/gi/types.py", line 113, in function
    return info.invoke(*args, **kwargs)
TypeError: fill() takes exactly 4 arguments (3 given)

Updating the system to gnome 3.14 specifically pygobject3-base this issue goes away.



Fri, 29 Jul 2016 01:29:59 GMT - Antoine Martin: status changed

Looks like what r11506 is meant to solve.


Fri, 29 Jul 2016 10:44:36 GMT - Antoine Martin: owner, status changed

Found a problem with centos 7.1 packaging, surprised that you didn't hit this: r13118.

Yes, you cannot update pygobject without breaking everything else horribly. Don't do that.

The fix for the sound issue is in r13121 + r13122 (optional: r13123), but unfortunately that is not enough to make it work on centos < 7.2: the sound subprocess ends up being killed within a few seconds.. Running with "-d all" or just "-d sound,gstreamer" shows nothing suspicious, the pipe just dies for no apparent reason. gdb shows an error deep in gobject / gstreamer. And that's all I've got time for!


Fri, 29 Jul 2016 10:45:03 GMT - Antoine Martin: attachment set

backtrace from gdb


Fri, 29 Jul 2016 17:23:42 GMT - Smo: owner changed


Sat, 30 Jul 2016 06:34:18 GMT - Antoine Martin:

@smo: can you help me with this? The centos 7.0 and 7.1 builds now fail trying to apply the patch:

Patch #1 (centos7-buffer-fill-fix.patch):
+ /usr/bin/cat /usr/src/rpmbuild/SOURCES/centos7-buffer-fill-fix.patch
+ /usr/bin/patch -p1 --fuzz=0
can't find file to patch at input line 5
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|Index: xpra/sound/gstreamer_util.py
|===================================================================
|--- a/xpra/sound/gstreamer_util.py
|+++ b/xpra/sound/gstreamer_util.py
--------------------------
File to patch:
Skip this patch? [y]
Skipping patch.
1 out of 1 hunk ignored
error: Bad exit status from /var/tmp/rpm-tmp.UN5O3x (%prep)

Despite the fact that patch applies cleanly. No idea what is going on here.


Tue, 02 Aug 2016 23:22:12 GMT - Smo: owner changed

I suspect you have to

cd $RPM_BUILD_DIR/xpra-%{version}

before running patch

How come on my system the value of %{?dist} always == .el7.centos and on yours you can get the different variants?


Wed, 03 Aug 2016 00:35:23 GMT - Antoine Martin: owner changed

I suspect you have to cd...


Doh: r13181.


How come on my system the value of %{?dist} always == .el7.centos


I use (edit: I had originally posted the one used on Fedora):

FULL_VERSION_STR=`cat /etc/redhat-release | sed 's/[^0-9\.]//g' | sed 's+\.+_+g' | cut -d_  -f 1-2`

then I pass \"dist .el${FULL_VERSION_STR}\" to rpmbuild to be able to differentiate them. I'll gladly change it for something more "standard". Or even move these statements inside the spec file to have it more self-contained. (and also stop overriding "dist" in the process)


Wed, 03 Aug 2016 06:00:05 GMT - Antoine Martin:

Also seeing the same issue with Debian Wheezy and Ubuntu Precise: #1275. Looks like a problem with the gstreamer bindings.


Wed, 03 Aug 2016 10:53:21 GMT - Antoine Martin:

r13194 kinda fixes that by changing the default to XPRA_GSTREAMER1=0. It seems to work well for Debian Wheezy and Ubuntu Precise. It "kinda" works for centos 7.0 / 7.1.. except when it doesn't: the client sometimes hangs on startup as the gstreamer 0.10 plugins are being probed via xpra _sound_query. SIGINT shows:

Traceback (most recent call last):
  File "/usr/lib64/python2.7/site-packages/gobject/__init__.py", line 57, in __init__
    def __init__(cls, name, bases, dict_):
KeyboardInterrupt

Running the client with "-d all" shows it hanging at:

import_gst0_10() pygst=<module 'pygst' from '/usr/lib64/python2.7/site-packages/pygst.pyc'>

Running it under gdb shows that the plugin loader is spawning tens of thousands of processes!

Detaching after fork from child process 30794.
Detaching after fork from child process 30795.
Detaching after fork from child process 30796.
^C
Program received signal SIGINT, Interrupt.
0x00007fba94eb6be9 in ppoll () from /lib64/libc.so.6
(gdb) bt
#0  0x00007fba94eb6be9 in ppoll () from /lib64/libc.so.6
#1  0x00007fba864edc15 in gst_poll_wait () from /lib64/libgstreamer-0.10.so.0
#2  0x00007fba864eae6e in exchange_packets () from /lib64/libgstreamer-0.10.so.0
#3  0x00007fba864ebd68 in plugin_loader_sync_with_child () from /lib64/libgstreamer-0.10.so.0
#4  0x00007fba864ebedb in gst_plugin_loader_try_helper () from /lib64/libgstreamer-0.10.so.0
#5  0x00007fba864ec010 in gst_plugin_loader_spawn.part.3 () from /lib64/libgstreamer-0.10.so.0
#6  0x00007fba864ec1ef in plugin_loader_replay_pending () from /lib64/libgstreamer-0.10.so.0
#7  0x00007fba864ec338 in plugin_loader_free () from /lib64/libgstreamer-0.10.so.0
#8  0x00007fba864f577d in gst_update_registry () from /lib64/libgstreamer-0.10.so.0
#9  0x00007fba864ab835 in init_post () from /lib64/libgstreamer-0.10.so.0
#10 0x00007fba87adfe28 in g_option_context_parse () from /lib64/libglib-2.0.so.0
#11 0x00007fba864ac15d in gst_init_check () from /lib64/libgstreamer-0.10.so.0
#12 0x00007fba8701fe29 in init_gst () from /usr/lib64/python2.7/site-packages/gst-0.10/gst/_gst.so
#13 0x00007fba95ba5eb9 in _PyImport_LoadDynamicModule () from /lib64/libpython2.7.so.1.0
#14 0x00007fba95ba3f91 in import_submodule () from /lib64/libpython2.7.so.1.0
#15 0x00007fba95ba41dd in load_next () from /lib64/libpython2.7.so.1.0
#16 0x00007fba95ba4bbe in PyImport_ImportModuleLevel () from /lib64/libpython2.7.so.1.0
#17 0x00007fba95b8b3bf in builtin___import__ () from /lib64/libpython2.7.so.1.0
#18 0x00007fba95afb073 in PyObject_Call () from /lib64/libpython2.7.so.1.0
#19 0x00007fba95b8cfd7 in PyEval_CallObjectWithKeywords () from /lib64/libpython2.7.so.1.0
#20 0x00007fba95b8eaa3 in PyEval_EvalFrameEx () from /lib64/libpython2.7.so.1.0
#21 0x00007fba95b9318d in PyEval_EvalCodeEx () from /lib64/libpython2.7.so.1.0
#22 0x00007fba95b93292 in PyEval_EvalCode () from /lib64/libpython2.7.so.1.0
#23 0x00007fba95ba307c in PyImport_ExecCodeModuleEx () from /lib64/libpython2.7.so.1.0
#24 0x00007fba95ba32f8 in load_source_module () from /lib64/libpython2.7.so.1.0
#25 0x00007fba95ba478a in load_package () from /lib64/libpython2.7.so.1.0
#26 0x00007fba95ba3f91 in import_submodule () from /lib64/libpython2.7.so.1.0
#27 0x00007fba95ba4276 in load_next () from /lib64/libpython2.7.so.1.0
#28 0x00007fba95ba4bbe in PyImport_ImportModuleLevel () from /lib64/libpython2.7.so.1.0
#29 0x00007fba95b8b3bf in builtin___import__ () from /lib64/libpython2.7.so.1.0
#30 0x00007fba95afb073 in PyObject_Call () from /lib64/libpython2.7.so.1.0
#31 0x00007fba95b8cfd7 in PyEval_CallObjectWithKeywords () from /lib64/libpython2.7.so.1.0
#32 0x00007fba95b8eaa3 in PyEval_EvalFrameEx () from /lib64/libpython2.7.so.1.0
#33 0x00007fba95b91930 in PyEval_EvalFrameEx () from /lib64/libpython2.7.so.1.0
#34 0x00007fba95b91930 in PyEval_EvalFrameEx () from /lib64/libpython2.7.so.1.0
#35 0x00007fba95b91930 in PyEval_EvalFrameEx () from /lib64/libpython2.7.so.1.0
#36 0x00007fba95b91930 in PyEval_EvalFrameEx () from /lib64/libpython2.7.so.1.0
#37 0x00007fba95b91930 in PyEval_EvalFrameEx () from /lib64/libpython2.7.so.1.0
#38 0x00007fba95b9318d in PyEval_EvalCodeEx () from /lib64/libpython2.7.so.1.0
#39 0x00007fba95b93292 in PyEval_EvalCode () from /lib64/libpython2.7.so.1.0
#40 0x00007fba95bac6cf in run_mod () from /lib64/libpython2.7.so.1.0
#41 0x00007fba95bad88e in PyRun_FileExFlags () from /lib64/libpython2.7.so.1.0
#42 0x00007fba95baeb19 in PyRun_SimpleFileExFlags () from /lib64/libpython2.7.so.1.0
#43 0x00007fba95bbfb1f in Py_Main () from /lib64/libpython2.7.so.1.0
#44 0x00007fba94decaf5 in __libc_start_main () from /lib64/libc.so.6
#45 0x0000000000400721 in _start ()
(gdb)

Looks like yet another bug with the gstreamer / gobject bindings in centos. yay.

Note: we don't include dependencies for sound plugins with the centos packages, so you will need to install the gstreamer 0.10 packages separately - and you may be able to remove the gstreamer1 packages.

The same fix will be applied to the deb builds (#1275).


Wed, 03 Aug 2016 11:15:51 GMT - Antoine Martin: summary changed

(better ticket summary)


Thu, 04 Aug 2016 18:13:55 GMT - Smo: owner changed

I'm still trying to reproduce the lockups on startup. I haven't been able to hit this bug yet.

I tested for a full day with gstreamer 0.10 and everything seems good to me.

I should note I was testing with client and server 0.17.4 should I be testing this with trunk instead?


Fri, 05 Aug 2016 01:31:16 GMT - Antoine Martin: owner changed

It would help to know if the bug is in trunk only, in which case we can expect to find a fix by undoing some changes. I never test older branches first.


Thu, 11 Aug 2016 16:38:16 GMT - Smo:

Switching back to gstreamer 0.10 seems to work fine. Will check trunk to see if I can reproduce the freeze on startup.


Tue, 20 Sep 2016 19:36:21 GMT - Smo: status changed; resolution set

I can sometimes get a freeze on startup but it isn't very consistent. Still suggest we stay back to gstreamer 0.10 for these not so up to date platforms.


Sat, 23 Jan 2021 05:19:35 GMT - migration script:

this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/1267