sound issues with CentOS 7.1.1503 - gstreamer1

[totaam]

Issue migrated from trac ticket # 1267

component: client | priority: major | resolution: fixed | keywords: sound centos

2016-07-28 20:20:02: smo created the issue

---

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.

[totaam]

2016-07-29 02:30:00: antoine changed status from new to assigned

[totaam]

2016-07-29 02:30:00: antoine commented

---

Looks like what r11506 is meant to solve.

[totaam]

2016-07-29 11:44:37: antoine changed status from assigned to new

[totaam]

2016-07-29 11:44:37: antoine changed owner from antoine to amo

[totaam]

2016-07-29 11:44:37: antoine commented

---

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!

[totaam]

2016-07-29 11:45:03: antoine uploaded file centos71-gsterr.txt (5.3 KiB)

backtrace from gdb

[totaam]

2016-07-29 18:23:42: smo changed owner from amo to smo

[totaam]

2016-07-30 07:34:18: antoine commented

---

@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.

[totaam]

2016-08-03 00:22:12: smo changed owner from smo to antoine

[totaam]

2016-08-03 00:22:12: smo commented

---

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?

[totaam]

2016-08-03 01:35:23: antoine changed owner from antoine to smo

[totaam]

2016-08-03 01:35:23: antoine commented

---

I suspect you have to cd...
[[BR]]
Doh: r13181.

[[BR]]

How come on my system the value of %{?dist} always == .el7.centos
[[BR]]
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)

[totaam]

2016-08-03 07:00:05: antoine commented

---

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

[totaam]

2016-08-03 11:53:21: antoine commented

---

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).

[totaam]

2016-08-03 12:15:52: antoine changed title from Sound issue with CentOS 7.1 1503 and Gnome 3.8 to sound issues with CentOS 7.1.1503 - gstreamer1

[totaam]

2016-08-03 12:15:52: antoine commented

---

(better ticket summary)

[totaam]

2016-08-04 19:13:56: smo changed owner from smo to antoine

[totaam]

2016-08-04 19:13:56: smo commented

---

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?

[totaam]

2016-08-05 02:31:16: antoine changed owner from antoine to smo

[totaam]

2016-08-05 02:31:16: antoine commented

---

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.

[totaam]

2016-08-11 17:38:16: smo commented

---

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

[totaam]

2016-09-20 20:36:21: smo changed status from new to closed

[totaam]

2016-09-20 20:36:21: smo set resolution to fixed

[totaam]

2016-09-20 20:36:21: smo commented

---

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.