xpra server crashed with BadWindow error

[adienakhmad]

Describe the bug
I've been trying out xpra for 2 weeks now, and I've got pretty consistent crash when closing dialog in Jetbrains Rider

To Reproduce
Steps to reproduce the behavior:

1. server command
   xpra start :12 --bind-tcp=0.0.0.0:9006 --resize-display=yes --webcam=no --microphone=disabled --speaker=disabled

2. client command
   none, I'm using the GUI session launcher

3. specific action to trigger the bug
   opening and closing Jetbrain Rider Settings dialog

System Information (please complete the following information):

• Server OS: Debian Bookworm VM
• Client OS: Windows 11 22H2
• Xpra Server Version xpra v4.4.6-r29
• Xpra Client Version xpra v4.4.6 revision 29

Additional context
Here's the server log after the crash

2023-07-21 09:51:39,285 Warning: found large packet
2023-07-21 09:51:39,285  'new-window' packet is 6231 bytes:
2023-07-21 09:51:39,285  argument types: <class 'int'>, <class 'int'>, <class 'int'>, <class 'int'>, <class 'int'>, <class 'dict'>, <class 'dict'>
2023-07-21 09:51:39,285  sizes: 3, 3, 1, 4, 3, 6366, 2
2023-07-21 09:51:39,286  packet: [27, 519, 361, 0, 1078, 799, {'xid': '0x1207350' .. ested-position': (361, 0), 'iconic': False}, {}]

(Xpra:14566): Gdk-WARNING **: 09:51:39.747: The program 'Xpra' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadWindow (invalid Window parameter)'.
  (Details: serial 1394525 error_code 3 request_code 7 (core protocol) minor_code 0)
  (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.)

When this happens, I usually run xpra list on the server, waiting until the session is cleaned up,

Found the following xpra sessions:
/run/user/1000/xpra/12:
        UNKNOWN session at :12
/run/user/1000/xpra:
        UNKNOWN session at :12
/home/adien/.xpra:
        UNKNOWN session at :12
Re-probing unknown sessions in: /run/user/1000/xpra, /run/user/1000/xpra/12, /home/adien/.xpra
        UNKNOWN session at :12 (cleaned up)
        UNKNOWN session at :12 (cleaned up)
        UNKNOWN session at :12 (cleaned up)

and re run the start command above, then I can get back to what everything was before the crash.

[totaam]

The error was 'BadWindow (invalid Window parameter)'.

This is usually the sign of a bug in xpra.

When this happens,

You should be able to just run xpra recover

--resize-display=yes

This is the default.

Warning: found large packet

This is harmless and will be silenced.

consistent crash when closing dialog in Jetbrains Rider

We take crasher bugs very seriously, so I went through the pain of registering, downloading and then finding that "settings" dialog.
I have opened and closed it at least 25 times in a row without triggering any crashes or even a warning.

Differences:

• I run Fedora 37
• xpra v5 beta

You may want to try a different OS or a different xpra version.
Failing that, please run with full debug and post the last few hundred lines of the server log before it crashes:

XPRA_X11_DEBUG_EVENTS="*" xpra start :12 --bind-tcp=0.0.0.0:9006 --webcam=no --microphone=disabled --speaker=disabled --debug all

[adienakhmad]

Hi @totaam thanks for the quick response, unfortunately when turning on the logs I can't reproduce the issue, timing issue perhaps?

In the meantime I'll keep the logs on as workaround, and if it does crash I'll post the logs here.

[totaam]

timing issue perhaps?

Sounds like it.

In the meantime I'll keep the logs on as workaround, and if it does crash I'll post the logs here.

Performance will be dreadful with full debug enabled.
You may get better results with --debug x11,events instead of --debug all.

[KondorIstvan]

We have the exact same issue using a commercial fluid dynamics solver running on our RHEL 8.7 server with xpra 4.4.6.

The crash is not deterministicqlly reproducible, but it happens within a few minutes every time.

We will test the logging workaround until newer packages become available (5.x for RHEL).

[totaam]

@KondorIstvan v5 has been released and packages are available.

[KondorIstvan]

@totaam I am aware of the release but RHEL & AlmaLinux repos provide only v4.4.6 for now.

Btw, the debug options did not help, I still got a crash. Log file attached.
server.log

[totaam]

There are 5.0 builds for all RHEL clones now.
The only ones that were still missing were AlmaLinux 8 / 9 and OracleLinux 8, both due to Xpra-org/repo-build-scripts#11

TILs:

2023-08-25 14:27:50,948 do_process_mouse_common(Protocol(unix-domain socket:/run/user/1002/xpra/12/socket), 32, (2025, 670, 97, 195), -1)
2023-08-25 14:27:50,948 <bound method XTestPointerDevice.click of XTestPointerDevice>(1, True, ())
2023-08-25 14:27:50,948 xtest_fake_button(1, True)
2023-08-25 14:27:51,029 x_event_filter event=('xpra-selection-request', None)/SelectionRequest window=0x40000d
2023-08-25 14:27:51,029 parse_event(..)=<X11:SelectionRequest {'send_event': '0', 'serial': '0x27782', 'delivered_to': '0x40000d', 'window': '0x40000d', 'requestor': '0xe00008', 'selection': 'CLIPBOARD', 'target': 'TARGETS', 'property': 'XAWT_TARGETS_OF_SELECTION:CLIPBOARD', 'time': '0'}>
2023-08-25 14:27:51,030 do_xpra_selection_request(<X11:SelectionRequest {'send_event': '0', 'serial': '0x27782', 'delivered_to': '0x40000d', 'window': '0x40000d', 'requestor': '0xe00008', 'selection': 'CLIPBOARD', 'target': 'TARGETS', 'property': 'XAWT_TARGETS_OF_SELECTION:CLIPBOARD', 'time': '0'}>)
2023-08-25 14:27:51,030 do_selection_request_event(<X11:SelectionRequest {'send_event': '0', 'serial': '0x27782', 'delivered_to': '0x40000d', 'window': '0x40000d', 'requestor': '0xe00008', 'selection': 'CLIPBOARD', 'target': 'TARGETS', 'property': 'XAWT_TARGETS_OF_SELECTION:CLIPBOARD', 'time': '0'}>)
2023-08-25 14:27:51,030 clipboard request for CLIPBOARD from window ['java-lang-Thread', 'xid=e00008', 'pid=379977'], target=TARGETS, prop=XAWT_TARGETS_OF_SELECTION:CLIPBOARD
2023-08-25 14:27:51,030 using existing TARGETS value as response: ('text/plain;charset=utf-8', 'UTF8_STRING', 'CF_UNICODETEXT', 'TEXT', 'STRING', 'text/plain')
2023-08-25 14:27:51,030 set_selection_response(<GdkX11.X11Window object at 0x7fa3108b9360 (GdkX11Window at 0x55983960f660)>, TARGETS, XAWT_TARGETS_OF_SELECTION:CLIPBOARD, ATOM, 32, b'\x88\x01\x00\x00\x00\x00\x00\x00\xe9\x00\x00\x .. x00\x00\x00\x00\x8b\x01\x00\x00\x00\x00\x00\x00', 0)
2023-08-25 14:27:51,030 x_event_filter event=('xpra-selection-request', None)/SelectionRequest took 0.7ms
2023-08-25 14:27:51,045 do_process_mouse_common(Protocol(unix-domain socket:/run/user/1002/xpra/12/socket), 32, (2025, 670, 97, 195), -1)
2023-08-25 14:27:51,045 <bound method XTestPointerDevice.click of XTestPointerDevice>(1, False, ())
2023-08-25 14:27:51,045 xtest_fake_button(1, False)
2023-08-25 14:27:51,095 x_event_filter event=('xpra-property-notify-event', None)/PropertyNotify window=0xe00386
2023-08-25 14:27:51,095 parse_event(..)=<X11:PropertyNotify {'send_event': '0', 'serial': '0x27793', 'delivered_to': '0xe00386', 'window': '0xe00386', 'atom': 'WM_TRANSIENT_FOR', 'time': '188906951'}>
2023-08-25 14:27:51,095 Property changed on 0xe00386: WM_TRANSIENT_FOR
2023-08-25 14:27:51,095 WM_TRANSIENT_FOR=<GdkX11.X11Window object at 0x7fa37a933d38 (GdkX11Window at 0x55983960fca0)>
2023-08-25 14:27:51,095 updateprop(transient-for, <GdkX11.X11Window object at 0x7fa37a933d38 (GdkX11Window at 0x55983960fca0)>) unchanged
2023-08-25 14:27:51,095 x_event_filter event=('xpra-property-notify-event', None)/PropertyNotify took 0.9ms
2023-08-25 14:27:51,096 x_event_filter event=('xpra-property-notify-event', None)/PropertyNotify window=0xe00386
2023-08-25 14:27:51,096 parse_event(..)=<X11:PropertyNotify {'send_event': '0', 'serial': '0x27794', 'delivered_to': '0xe00386', 'window': '0xe00386', 'atom': 'WM_TRANSIENT_FOR', 'time': '188906952'}>
2023-08-25 14:27:51,096 Property changed on 0xe00386: WM_TRANSIENT_FOR
2023-08-25 14:27:51,096 WM_TRANSIENT_FOR=<GdkX11.X11Window object at 0x7fa37a933d38 (GdkX11Window at 0x55983960fca0)>
2023-08-25 14:27:51,096 updateprop(transient-for, <GdkX11.X11Window object at 0x7fa37a933d38 (GdkX11Window at 0x55983960fca0)>) unchanged
2023-08-25 14:27:51,096 x_event_filter event=('xpra-property-notify-event', None)/PropertyNotify took 0.4ms
2023-08-25 14:27:51,096 x_event_filter event=('xpra-property-notify-event', None)/PropertyNotify window=0xe00386
2023-08-25 14:27:51,096 parse_event(..)=<X11:PropertyNotify {'send_event': '0', 'serial': '0x27794', 'delivered_to': '0xe00386', 'window': '0xe00386', 'atom': 'WM_HINTS', 'time': '188906952'}>
2023-08-25 14:27:51,096 Property changed on 0xe00386: WM_HINTS
2023-08-25 14:27:51,096 getWMHints(0xe00386)={'input': 0, 'window_group': 14680134}
2023-08-25 14:27:51,096 updateprop(group-leader, <GdkX11.X11Window object at 0x7fa37a933d38 (GdkX11Window at 0x55983960fca0)>) unchanged
2023-08-25 14:27:51,096 updateprop(attention-requested, False) unchanged
2023-08-25 14:27:51,096 wm_hints.input = 0
2023-08-25 14:27:51,096 x_event_filter event=('xpra-property-notify-event', None)/PropertyNotify took 0.4ms
2023-08-25 14:27:51,097 x_event_filter event=('xpra-unmap-event', 'xpra-child-unmap-event')/UnmapNotify window=0xe00386
2023-08-25 14:27:51,097 parse_event(..)=<X11:UnmapNotify {'send_event': '0', 'serial': '0x27794', 'delivered_to': '0xe00386', 'window': '0xe00386'}>
2023-08-25 14:27:51,097 do_xpra_unmap_event(<X11:UnmapNotify {'send_event': '0', 'serial': '0x27794', 'delivered_to': '0xe00386', 'window': '0xe00386'}>) client window unmapped, last_unmap_serial=0x0
2023-08-25 14:27:51,097 unmanaging window: WindowModel(0xe00386) (<GdkX11.X11Window object at 0x7fa3108cf708 (GdkX11Window at 0x5598397ba4b0)> - <GdkX11.X11Window object at 0x7fa3108163f0 (GdkX11Window at 0x5598397ba000)>)

(Xpra:376443): Gdk-ERROR **: 14:27:51.099: The program 'Xpra' received an X Window System error.

Does the crash go away if you run with --no-clipboard?
Otherwise, the crash may be caused by another GTK window leak issue.
If that's the case, 5.0 may fix it. If not, then we will need #3871

[KondorIstvan]

v5.0 fixed our crashes with this error!

[totaam]

There's a good chance that this bug was the same as #3822

All older branches still have this bug, including 3.1.x (now EOL) and all 4.x releases.