Xpra: Ticket #2640: xpra shadow crashes inside xpra client with --opengl=no

From client: r25603

$ "Xpra-Python3-x86_64_4.0-r25603\xpra_cmd" start ssh://user@ip/2 --ssh="plink -ssh -agent" --modal-windows=no --microphone=off --speaker=off --webcam=no --pulseaudio=no --opengl=no --start-new-commands=yes --start=gnome-terminal

To Xenial server: v3.0.7-r25609

$ xpra shadow ssh://host@host
xpra for python 2.7 is not installed
 retrying with python3
2020-03-13 01:12:35,685 Xpra GTK3 X11 client version 3.0.7-r25609 64-bit
2020-03-13 01:12:35,757  running on Linux Ubuntu 16.04 xenial
2020-03-13 01:12:35,758  window manager is 'Xpra'
2020-03-13 01:12:35,785 Warning: failed to query pulseaudio using 'pactl info'
2020-03-13 01:12:35,785  Connection failure: Connection refused
2020-03-13 01:12:35,786  pa_context_connect() failed: Connection refused
2020-03-13 01:12:35,862 No OpenGL_accelerate module loaded: No module named 'OpenGL_accelerate'
(xpra:7522): Gdk-ERROR **: The program 'xpra' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadValue (integer parameter out of range for operation)'.
  (Details: serial 231 error_code 2 request_code 151 (GLX) minor_code 3)
  (Note to programmers: normally, X errors are reported asynchronously;
   that is, you will receive the error a while after causing it.
   To debug your program, run it with the GDK_SYNCHRONIZE environment
   variable to change this behavior. You can then get a meaningful
   backtrace from your debugger if you break on the gdk_x_error() function.)
Trace/breakpoint trap (core dumped)

To Bionic server v4.0-r25532



Fri, 13 Mar 2020 05:00:16 GMT - Antoine Martin: owner changed

This looks like an opengl crash in the xenial opengl client. Does this work if you disable opengl in the shadow command?

If not, can you run with -d opengl and get more details? How big is the screen you're trying to shadow?


Fri, 13 Mar 2020 09:31:50 GMT - stdedos:

Yes, it does. I was thinking; could the client automatically detect that OpenGL is disabled and not try it at all?

$ DISPLAY=:0 xrandr | grep -vP '^\s[^*]+$'
Screen 0: minimum 320 x 200, current 3520 x 1080, maximum 16384 x 16384
LVDS-1 connected primary 1600x900+0+0 (normal left inverted right x axis y axis) 309mm x 174mm
   1600x900      60.04*+  59.99    59.94    59.95    40.00    59.82
VGA-1 disconnected (normal left inverted right x axis y axis)
HDMI-1 disconnected (normal left inverted right x axis y axis)
DP-1 disconnected (normal left inverted right x axis y axis)
HDMI-2 disconnected (normal left inverted right x axis y axis)
HDMI-3 connected 1920x1080+1600+0 (normal left inverted right x axis y axis) 509mm x 286mm
   1920x1080     60.00*+
DP-2 disconnected (normal left inverted right x axis y axis)
DP-3 disconnected (normal left inverted right x axis y axis)

Fri, 13 Mar 2020 09:42:23 GMT - Antoine Martin:

Yes, it does. I was thinking; could the client automatically detect that OpenGL is disabled and not try it at all?

I don't think that this is possible. That's why we probe opengl in a subprocess, if that crashes or exits with an error, we disable opengl.

Did your client connect or not? The opengl crash during probing should be harmless.


Fri, 13 Mar 2020 14:09:07 GMT - stdedos:

Did your client connect or not? The opengl crash during probing should be harmless.

No, the client did not connect. The command just returned with $?:133, with no server instanciated.


Fri, 13 Mar 2020 15:04:44 GMT - Antoine Martin:

Please attach the output of:

xpra shadow ssh://host@host -d all

(and maybe just -d opengl too)


Thu, 19 Mar 2020 15:45:28 GMT - Antoine Martin: owner, status changed

The problem I can reproduce on my xenial systems is that the opengl option is set to auto rather than probe and so the crash may affect the client command instead of being run in a subcommand.

It still doesn't explain why it crashes on your system: mine just correctly detects that something is not right. With python2 just a BadMatch, the Ubuntu Xenial python3 opengl libraries are completely unusable it seems.

But if you used --opengl=probe, I bet the xpra command would not crash, it would just continue without opengl after the test subcommand crashes.


Thu, 19 Mar 2020 16:13:11 GMT - Antoine Martin: owner, status changed

Turns out that I had an configuration file installed in /usr/local/etc/xpra/. I suspect that something similar is happening on your system.

xpra showconfig | grep opengl

Should show probe as value. If not, you may hit problems like the one above.


Fri, 20 Mar 2020 08:01:21 GMT - Antoine Martin: status changed; resolution set


Sat, 23 Jan 2021 05:56:47 GMT - migration script:

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