Opened 19 months ago
Last modified 18 months ago
#1853 closed defect
After connection timeout, Xpra-Launcher.exe does not terminate but stays as a zombie process — at Version 1
Reported by: | Lukas Haase | Owned by: | Antoine Martin |
---|---|---|---|
Priority: | major | Milestone: | 2.4 |
Component: | client | Version: | 2.3.x |
Keywords: | Cc: |
Description (last modified by )
For quite a long time (at least 2.1.3, r17250) but also with the newest 2.3 (r19246) I suffer from the following issue:
In Windows 10, when the connection to an xpra server drops I get the usual message (TortoisePlink Fatal Error Network error: Software caused connection abort) and then I quit the Xpra dialog (which invites me to reconnect) but then Xpra-Launcher.exe stays as zombie process in the task manager forever until I manually kill them.
Sometimes I use xpra so regularly that I end up having hundreds of zombies.
This effect does not show up when I manually quit the session via the context menu.
I start the session via an xpra file that has for example the following content:
username=user encoding=rgb ssh_port=22 speed=0 min-speed=0 host=terminal-server min-quality=30 mode=ssh ssh=plink -noagent -i c:\\Users\\user\\AppData\\Roaming\\Xpra\\pubkey.ppk opengl=yes password= quality=0 port=2012 autoconnect=True speaker=off
In case it helps I attach screenshots of Process Explorer showing the threads and the stack of such a zombie process. NtUserMsgWaitForMultipleObjectsEx
indicates to me that it waits for something (i.e. feedback from the connection) which never occurs.
Change History (4)
Changed 19 months ago by
Attachment: | threads.png added |
---|
Changed 19 months ago by
Attachment: | stack_msvcrt.png added |
---|
Changed 19 months ago by
Attachment: | stack_xpra_launcher.png added |
---|
comment:1 Changed 19 months ago by
Description: | modified (diff) |
---|---|
Milestone: | → 2.4 |
Status: | new → assigned |
Thanks for the detailed bug report, I'll try to reproduce.
The
NtUserMsgWaitForMultipleObjectsEx
is somewhere in glib, so we'll have to find a way to cancel that or just not get in that situation in the first place..