xpra icon
Bug tracker and wiki

Opened 4 months ago

Closed 4 months ago

Last modified 3 months ago

#2304 closed defect (fixed)

2.5+ individual windows become frozen and unkillable

Reported by: tc424 Owned by: Antoine Martin
Priority: critical Milestone: 3.0
Component: server Version: 2.5.x
Keywords: Cc:

Description

Client:
xpra 3.0-20190506r22647-1
Xubuntu 18.04.2

Server:
Xubuntu 16.04.6
xpra 2.5.1-r22431-1 and/or 3.0-20190506r22647-1

If I start up an xfce4-terminal inside xpra and "mess about" quickly with the menus, I get to a point where I can't type into the terminal or properly close it. Clicking the close button seems to eventually kill the underlying process, but the window remains visible in the client. Clicking in the zombie window causes underlying windows to pop-up, maybe suggesting that the window no longer exists on the server?

I have also seen this with gnucash and Google Chrome, but it seems to be most easily reproducible with xfce4-terminal.

Attachments (3)

Screencast 2019-05-18 12:03:25.mp4 (1.3 MB) - added by tc424 4 months ago.
(Attempted) demostration
xpra-server-log.txt (1.5 MB) - added by tc424 4 months ago.
Server log file
xpra-info.txt (178.0 KB) - added by tc424 4 months ago.

Change History (14)

Changed 4 months ago by tc424

(Attempted) demostration

Changed 4 months ago by tc424

Attachment: xpra-server-log.txt added

Server log file

comment:1 Changed 4 months ago by Antoine Martin

Owner: changed from Antoine Martin to tc424

Please capture xpra info after this happens.
Does the server still respond?
Does it happen if you start the server with:

XPRA_SYNCHRONIZE=1 xpra start ..

Does it happen if you run the server on Ubuntu 18.04 or newer?

Changed 4 months ago by tc424

Attachment: xpra-info.txt added

comment:2 Changed 4 months ago by tc424

Yes, seems to happen if I start a server on the 18.04 machine as well (interesting as I believe xfce4-terminal is Gtk3 based on 18.04, as opposed to using Gtk2 on 16.04.)

Using --sync-xvfb and x11vnc on the 16.04 machine, seems to confirm that the server and the client get out of sync - the client thinks there's a still a highlight active in the menu bar, which isn't there on Xvfb. Clicking to close window closes it on Xvfb but not the client.

comment:3 Changed 4 months ago by tc424

And yes, still seems to happen with XPRA_SYNCHRONIZE on.

comment:4 Changed 4 months ago by tc424

Oh, and yes, the server is otherwise responsive - other applications work, it shutdown when requested, etc.

comment:5 Changed 4 months ago by Antoine Martin

Does this happen with the gtk3 client? (install python3-xpra and run as python3 /usr/bin/xpra.
Try XPRA_SYNCHRONIZE with the client.
Also try enabling / disabling opengl.

comment:6 Changed 4 months ago by tc424

No difference with/without opengl.

No difference with XPRA_SYNCHRONIZE on the client.

The python3 client DOES make a difference - haven't yet managed to reproduce, will keep trying. Subjectively performance feels very slightly slower generally with python3, and specifically quite a lot worse when playing with the menus in xfce4-terminal.

I also have a font hinting issue with python3, but that'll be another ticket I guess..

comment:7 Changed 4 months ago by tc424

(Just realised I have sync-xvfb still on, which may partly explain performance issue.)

Much weirdness though - I left the xfce4-terminal I was playing with open, disconnected the python3 client, reconnected with the python2 client - and discovered the terminal has keyboard input locked out. Disconnect and reconnect with python3 client again and the keyboard input is fine.

So seems like the different clients are interpreting the server state differently?

comment:8 Changed 4 months ago by Antoine Martin

Owner: changed from tc424 to Antoine Martin
Priority: majorcritical
Status: newassigned

I can reproduce the problem on Fedora so I should be able to fix it.

The server log is full of client decoding error: unknown cause.

comment:9 Changed 4 months ago by Antoine Martin

More complete server log output:

2019-05-23 21:55:38,070 Warning: client decoding error:
2019-05-23 21:55:38,070  unknown cause
(... many more ...)
2019-05-23 21:55:57,593 Warning: mmap area is full!
2019-05-23 21:55:57,594  we need to store 2372664 bytes but only have 1733442 free space left

So not only is there a decoding error but we fail to free the mmap area which eventually causes it to overflow.

The strange thing is that the client output is clean, without any warnings there.
The server is responding and xpra info looks healthy.
One thing that does look odd is that the xfce4-terminal window doesn't seem to have widget-focus with python3: the menus are slightly greyed out.

comment:10 Changed 4 months ago by Antoine Martin

Resolution: fixed
Status: assignedclosed

The mmap bug is unrelated and is only made easier to trigger by this bug, this is fixed in r22770.

This bug was quite hard to find.
It was caused by r22384 and is fixed in r22773.
Re-using the same variable for an inner iterator caused the wrong window to be removed from our active list, all subsequent paint events ended up being dropped.

I will spin up new builds with this fix.

Thanks for the bug report!

comment:11 Changed 3 months ago by tc424

Just to confirm this doesn't seem to be reproducible here any more - thank you once again :)

Note: See TracTickets for help on using tickets.