Bug 2099767

Summary: xpra stops responding to input when connected for several days
Product: [Fedora] Fedora Reporter: Ian Collier <imc>
Component: xpraAssignee: Antonio T. sagitter <trpost>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 36CC: jonathan.underwood, sergio, tchollingsworth, trpost
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: xpra-4.3.4-1.fc36 xpra-4.3.4-1.fc35 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2022-07-07 01:15:39 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 2079969    
Bug Blocks:    

Description Ian Collier 2022-06-21 16:36:32 UTC
I have xpra sessions that are basically permanently connected.  Since upgrading
to Fedora 36, every 5-6 days if the client didn't restart for some other reason
(network problems, etc) then the xpra windows suddenly stop responding to
keyboard and mouse input, and the client spews messages on stderr roughly
every half-second:

** (Xpra:551221): WARNING **: 17:09:57.831: could not allocate closure
** (Xpra:551221): WARNING **: 17:09:58.331: could not allocate closure
** (Xpra:551221): WARNING **: 17:09:58.832: could not allocate closure

There's plenty of memory and the xpra process doesn't seem too excessive.

USER         PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
imc       551221  1.0  2.7 2715204 670336 pts/4  Sl   Jun16  79:24 /usr/bin/pyth

Killing the client takes two SIGTERM signals, then after reconnect everything
is fine so the problem is definitely client-side.

Installed version is: xpra-4.3.2-1.fc36.x86_64

Upstream version is currently 4.3.4 so I guess would be good to try that
before trying to debug this (unless the cause is obvious).

Comment 1 Fedora Update System 2022-06-28 18:06:41 UTC
FEDORA-2022-b2d2714057 has been submitted as an update to Fedora 35. https://bodhi.fedoraproject.org/updates/FEDORA-2022-b2d2714057

Comment 2 Fedora Update System 2022-06-28 18:06:42 UTC
FEDORA-2022-1b9ebcacd3 has been submitted as an update to Fedora 36. https://bodhi.fedoraproject.org/updates/FEDORA-2022-1b9ebcacd3

Comment 3 Fedora Update System 2022-06-29 01:17:49 UTC
FEDORA-2022-b2d2714057 has been pushed to the Fedora 35 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2022-b2d2714057`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-b2d2714057

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 4 Fedora Update System 2022-06-29 01:33:46 UTC
FEDORA-2022-1b9ebcacd3 has been pushed to the Fedora 36 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2022-1b9ebcacd3`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-1b9ebcacd3

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 5 Fedora Update System 2022-07-07 01:15:39 UTC
FEDORA-2022-1b9ebcacd3 has been pushed to the Fedora 36 stable repository.
If problem still persists, please make note of it in this bug report.

Comment 6 Fedora Update System 2022-07-07 01:17:53 UTC
FEDORA-2022-b2d2714057 has been pushed to the Fedora 35 stable repository.
If problem still persists, please make note of it in this bug report.