xvfb sometimes not stopped automatically

[totaam]

Issue migrated from trac ticket # 1241

component: server | priority: major | resolution: fixed

2016-06-30 23:03:36: floemker created the issue

---

With xpra 0.17.4 sometimes xvfb is not stopped when the client is stopped even when --exit-with-children is specified.

The client is started via:

xpra start ssh/rvm:192.168.2.126:22/100 --start-child=/RVM/bin/RWFileEd --exit-with-children

The server output of a successful run when xvfb is stopped as well as the output of a run when xvfb is not stopped is attached.

ps of the not stopped xvfb:[[BR]]

rvm       9559  0.4  4.0 242968 82084 ?        Ssl  17:48   0:01 Xvfb-for-Xpra-:100 +extension Composite -screen 0 5760x2560x24+32 -nolisten tcp -noreset -auth /home/rvm/.Xauthority :100

Client output:

2016-06-30 17:48:28,865 Warning: using fallback encryption library pycrypto
2016-06-30 17:48:28,865  python-cryptography is not available: No module named cryptography.hazmat.backends
2016-06-30 17:48:28,865 Xpra gtk2 client version 0.17.2-[r12591](../commit/1b3e5efa26a56fe9eee534778854535ad10bc03d)
2016-06-30 17:48:28,865  running on Linux Ubuntu 14.04 trusty
2016-06-30 17:48:28,865 Warning: failed to import opencv:
2016-06-30 17:48:28,865  No module named cv2
2016-06-30 17:48:28,865  webcam forwarding is disabled
Warning: failed to import GStreamer:
 GStreamer 1.0: Namespace Gst not available
 GStreamer 0.10: No module named pygst
2016-06-30 17:48:28,910 Error: failed to query sound subsystem:
2016-06-30 17:48:28,910  query did not return any data
[swscaler @ 0x1f96580] Warning: data is not aligned! This can lead to a speedloss
2016-06-30 17:48:29,100 PyOpenGL warning: missing accelerate module
2016-06-30 17:48:29,100 PyOpenGL warning: missing array format handlers: numeric, vbo, vbooffset
2016-06-30 17:48:29,100 OpenGL Version: 3.0 Mesa 10.1.3
2016-06-30 17:48:29,101 OpenGL support is missing:
2016-06-30 17:48:29,101  PyOpenGL version 3.1 or later is required (found version 3.0.2)
2016-06-30 17:48:31,924  detected keyboard: rules=evdev, model=pc104, layout=us
2016-06-30 17:48:31,925  desktop size is 1920x1080 with 1 screen:
2016-06-30 17:48:31,925   :0.0 (508x285 mm - DPI: 96x96) workarea: 1920x1045
2016-06-30 17:48:31,925     DVI-0 (510x287 mm - DPI: 95x95)
/RVM/sbin/SshdLog.sh: line 15: xpra: command not found
Entering daemon mode; any further errors will be reported to:
  /home/rvm/.xpra/:100.log
2016-06-30 17:48:36,971 Xpra X11 server version 0.17.4-[r12942](../commit/e5bbd224a997e395a2319706718861c87e1914be)
2016-06-30 17:48:36,971  running on Linux Ubuntu 14.04 trusty
2016-06-30 17:48:36,971 enabled remote logging
2016-06-30 17:48:41,199 server requested disconnect: server shutdown

I tried the same as well with client 0.17.4. The behavior is identical.

Distribution: Ubuntu 14.04.4 LTS[[BR]]
Kernel: Linux RVM 4.4.8 #2 SMP Wed Jun 8 17:59:51 EDT 2016 x86_64 x86_64 x86_64 GNU/Linux

[totaam]

2016-06-30 23:04:32: floemker uploaded file ServerError-100.log (5.7 KiB)

[totaam]

2016-06-30 23:04:47: floemker uploaded file ServerOk-100.log (5.8 KiB)

[totaam]

2016-07-12 17:52:23: antoine commented

---

Milestone renamed

[totaam]

2016-07-14 21:52:15: floemker commented

---

Further debugging showed that the cause is a SegV in libdbus:

  xpra[26878]: segfault at 4 ip 00007f192c32bd80 sp 00007ffe9df34158 error 6 in libdbus-1.so.3.7.6[7f192c308000+44000]

A backtrace for this SegV is attached.

I assume the reason is a missing call to dbus.mainloop.glib.threads_init().
It seems that after applying the attached patch there are no SegV's anymore
and xvfb is stopped always correctly.

[totaam]

2016-07-14 21:53:39: floemker uploaded file SegV-BackTrace.txt (40.2 KiB)

Backtrace for a SegV in libdbus-1.so.3.7.6

[totaam]

2016-07-14 21:54:11: floemker uploaded file DBusThreadsInit.patch (0.3 KiB)

Fix for missing call to dbus.mainloop.glib.threads_init().

[totaam]

2016-07-14 23:00:39: antoine changed owner from antoine to floemker

[totaam]

2016-07-14 23:00:39: antoine edited the issue description

[totaam]

2016-07-14 23:00:39: antoine commented

---

Many thanks, applied to trunk in r13013 and v0.17.x in 13014.

I'm not entirely sure what triggers this, I thought we only made calls to dbus from the main thread but clearly that's not the case, maybe we have some racy cleanup calls. Ideally. I would like to figure out why.. not sure I'll have enough time.
In any case, I don't see any harm in enabling threading in python dbus.

Can I close this ticket?

[totaam]

2016-07-15 14:42:41: floemker commented

---

Yes, here thread 4 and thread 1 called

Connection_send_message_with_reply_and_block()

at the same time. Closing the ticket is fine, I think.
At least initial tests worked.

[totaam]

2016-07-15 14:43:39: antoine commented

---

I should have verified those changes before applying them... breakage ensued.

Fixups: r13018 + 13019.

[totaam]

2016-08-10 05:23:38: antoine changed status from new to closed

[totaam]

2016-08-10 05:23:38: antoine set resolution to fixed