This does not happen every time I launch thunderbird, but sometimes. The following error shows up in server's log before the crash:
2017-03-01 21:23:10,833 started command 'thunderbird' with pid 7119 [xcb] Unknown sequence number while processing queue [xcb] Most likely this is a multi-threaded client and XInitThreads has not been called [xcb] Aborting, sorry about that.
I was able to revive the session with xpra upgrade
afterwards
I have seen this very occasionally and indicates a bug in xpra. Unfortunately, I have not been able to reproduce it reliably. If you can reproduce it, please attach the end of the server's "-d all" log.
Attached last 1k lines of log. With -d all
the only new info at the moment of the crash is the python error.
Another crash upon connecting, with IO error 11. X server is alive and session can be restored with xpra upgrade
...also I can not seem to launch xpra on server anymore, it outputs this:
$ xpra start :100 using systemd-run to wrap 'start' server command 'systemd-run' '--description' 'xpra-start' '--scope' '--user' '/usr/bin/xpra' 'start' ':100' '--systemd-run=no' Failed to create bus connection: No such file or directory
Remote start works though.
Lots of goodies in those log samples. What distro is this? What exact command lines?
Here's a list of significant events leading up to this last crash:
02:14:57,051 client closed window 2 - WindowModel(0x4000b4) 02:14:57,051 sending WM_DELETE_WINDOW to 0x4000b4
02:14:57,195 x_event_filter event=('xpra-unmap-event', 'xpra-child-unmap-event')/UnmapNotify window=0x4000b4 02:14:57,197 unmanaging window: WindowModel(0x4000b4) \ (<gtk.gdk.Window object at 0x7f772463fa00 (GdkWindow at 0x5627d55ea000)> - \ <gtk.gdk.Window object at 0x7f772463f6e0 (GdkWindow at 0x5627d5597480)>)
02:14:57,200 XError XError: BadWindow detected while already in unwind; discarding
02:14:57,200 add_packet_to_queue(lost-window ...)
02:14:57,233 x_event_filter event=('xpra-focus-out-event', None)/FocusOut took 4.7ms 02:14:57,233 get_cursor_data() cursor=[1072, 542, 16, 16, 7, 7, 1L, '1024 bytes', ''] 02:14:57,234 get_cursor_data(): default cursor - clearing it
02:14:58,819 x_event_filter event=('xpra-destroy-event', None)/DestroyNotify took 0.2ms 02:14:58,819 x_event_filter event=('xpra-unmap-event', 'xpra-child-unmap-event')/UnmapNotify window=0x4000f3 02:14:58,819 SystemTray.do_xpra_unmap_event(<X11:UnmapNotify \ {'delivered_to': '0x4000f3', 'send_event': 0, 'window': '0x4000f3', 'serial': '0x175c', 'type': 18, \ 'display': <gtk.gdk.DisplayX11 object at 0x7f773896fa00 (GdkDisplayX11 at 0x5627d4cf7000)>}>) \ container window=<gtk.gdk.Window object at 0x7f772463f500 (GdkWindow at 0x5627d5597ea0)> 02:14:58,821 lost_window: 1 - SystemTrayWindowModel(0x20002e) 02:14:58,821 add_packet_to_queue(lost-window ...)
02:14:58,835 sigchld(17, <frame object at 0x7f7710003610>) 02:14:58,835 poll() procinfo list: [ProcInfo({'returncode': None, 'name': 'thunderbird', 'process': <subprocess.Popen object at 0x7f77232b1450>, \ 'pid': 9936, 'dead': False, 'ignore': False, 'callback': None, 'command': ['thunderbird'], 'forget': False})] 02:14:58,835 add_dead_process(ProcInfo({'returncode': None, 'name': 'thunderbird', 'process': <subprocess.Popen object at 0x7f77232b1450>, \ 'pid': 9936, 'dead': False, 'ignore': False, 'callback': None, 'command': ['thunderbird'], 'forget': False})) 02:14:58,835 add_dead_process returncode=0, dead=True, callback=None 02:14:58,835 child 'thunderbird' with pid 9936 has terminated
02:15:03,579 read thread: eof
02:15:05,543 processing packet hello
02:15:19,201 will process ui packet start-command 02:15:19,201 start new command: ['start-command', 'thunderbird', 'thunderbird', False, True]
It would save me a lot of time to know that I only really care about the last few entries!
This was done on Current Debian testing, 64bit, xpra 2.0 r15180. Thunderbird with firetray extension.
Server launched with remote xpra start ssh:...:100 -d all
At some point it was re-launched after crash with the same X session by xpra upgrade :100
locally on the server, if I remember correctly. (local xpra start
does not work).
I have seen the crash - not sure how to reproduce it reliably yet. Hints would be welcome.
@psycho_zs: I am unable to make it crash now that I am ready to investigate it :(
I've stopped and restarted thunderbird dozens of times using xpra control :3 start thunderbird
.
Then I hit a different bug when running debian stretch: we seem to be crashing handling the initial info request, it could be the same bug.
If you can reproduce the thunderbird one easily, can you try:
--- xpra/client/ui_client_base.py (revision 15219) +++ xpra/client/ui_client_base.py (working copy) @@ -1981,7 +1981,7 @@ gui_ready() if self.tray: self.tray.ready() - self.send_info_request() + #self.send_info_request() def handshake_complete(self): oh = self._on_handshake
Identified the initial connection problem - hopefully this is the last one: #1430. The patch suggested in comment:8 should avoid causing the crash so easily, but the correct fix will prevent any "info" query from causing crashes.
Bug squashed, see ticket:1430#comment:4. This affected both 1.0.x and trunk.
@psycho_zs: I would really appreciate if you could try to break it again now that I have committed those fixes. I am quite confident the fixes are correct, but there may still be another bug lurking somewhere. To make it easier I have posted updated Debian Stretch beta packages (both trunk and v1.0.4): http://xpra.org/beta.
no crash yet, local start works. But server drains CPU when client is connected, attached new error spam.
@psycho_zs: great news - thank you, the error you are seeing is unrelated to the crash (was caused by r15205, fixed in r15222)
I am closing this ticket for now, but feel free to re-open it. I will still look into this as part of #1430.
Note: the only way you can hit this codepath is if you have opengl client rendering disabled... which is not recommended.
With opengl on I have redraw issues on window resize (just re-checked on Intel, mesa 17.0.0), so I leave that disabled. Will see if I'm able to catch the crash again.
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/1456