xpra icon
Bug tracker and wiki

Opened 6 months ago

Closed 6 months ago

#2640 closed defect (needinfo)

xpra shadow crashes inside xpra client with --opengl=no

Reported by: stdedos Owned by: stdedos
Priority: minor Milestone: 4.0
Component: client Version: 3.0.x
Keywords: Cc:

Description

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

Change History (8)

comment:1 Changed 6 months ago by Antoine Martin

Owner: changed from Antoine Martin to stdedos

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?

comment:2 Changed 6 months ago by 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)

comment:3 Changed 6 months ago by 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.

comment:4 in reply to:  3 Changed 6 months ago by 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.

Last edited 6 months ago by Antoine Martin (previous) (diff)

comment:5 Changed 6 months ago by Antoine Martin

Please attach the output of:

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

(and maybe just -d opengl too)

comment:6 Changed 6 months ago by Antoine Martin

Owner: changed from stdedos to Antoine Martin
Status: newassigned

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.

comment:7 Changed 6 months ago by Antoine Martin

Owner: changed from Antoine Martin to stdedos
Status: assignednew

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.

comment:8 Changed 6 months ago by Antoine Martin

Resolution: needinfo
Status: newclosed
Note: See TracTickets for help on using tickets.