xpra client not timing out

[totaam]

Issue migrated from trac ticket # 2131

component: client | priority: major | resolution: fixed

2019-02-01 13:04:50: stdedos created the issue

---

2019-02-01 14:04:09,233 Xpra shadow server version 2.5-[r21480](../commit/7e36724eb2113ca1cf8d745874058bf3c5826c03) 64-bit
2019-02-01 14:04:09,234  running on Linux Ubuntu 16.04 xenial

and

2019-02-01 14:03:37,543 Xpra GTK3 client version 2.5-[r21454](../commit/5562fb4144e749efb368ee3bf0c242bfb03675be) 64-bit
2019-02-01 14:03:37,548  running on Microsoft Windows 10

xpra client is Xpra-Python3-x86_64_Setup_2.5-r21454.exe

The shadow session was (probably?) in some kind of limbo state; however, client didn't try to time it out.

-Note:* I am not entirely sure if these are the correct server file, since xpra is only archiving at most one backup. However, since it was the bigger file, I thought it might have been useful.

Server uses ethernet, client uses wi-fi, but they are "on the same network". Assume infinite bandwidth.

[totaam]

2019-02-01 13:05:14: stdedos uploaded file xpra-ticket-#2131.zip (53.9 KiB)

[totaam]

2019-02-01 13:14:06: stdedos uploaded file Xpra_cmd_2019-02-01_15-12-57.png (42.2 KiB)

xpra-py2

[totaam]

2019-02-01 13:15:08: stdedos commented

---

It seems that xpra is not picking up... screenshot is from Xpra-x86_64_Setup_2.5-[r21454](../commit/5562fb4144e749efb368ee3bf0c242bfb03675be) (again, same network).

I'll try to downgrade

[totaam]

2019-02-01 13:40:09: stdedos uploaded file xpra-ticket-#2131-downgrade_pointer-issue.zip (279.5 KiB)

[totaam]

2019-02-01 13:42:02: stdedos uploaded file Xpra_cmd_2019-01-22_13-44-17_pointer-offset.png (25.1 KiB)

[totaam]

2019-02-01 13:44:34: stdedos commented

---

Even downgrading server to r20740 (xpra --version == v2.5-[r21480](../commit/7e36724eb2113ca1cf8d745874058bf3c5826c03)) and xpra client to 2.5-[r20836](../commit/fbc1958c1f7413e62e59f1a361c5aea99ab01a31)., still no dice.

---

Timeouts in older version get a bit "easier to handle" with clipboard=no, but they don't go away.

# * The offset on .0:0 could be explained that the (leftmost) screen is "smaller" than the other ones:

$  xrandr
Screen 0: minimum 8 x 8, current 5520 x 1080, maximum 16384 x 16384
DVI-I-0 disconnected (normal left inverted right x axis y axis)
DVI-I-1 connected primary 1680x1050+0+30 (normal left inverted right x axis y axis) 474mm x 296mm
   1680x1050     59.88*+  59.95  
   1280x1024     75.02    60.02  
   1152x864      75.00  
   1024x768      75.03    60.00  
   800x600       75.00    60.32  
   640x480       75.00    59.94  
DP-0 disconnected (normal left inverted right x axis y axis)
HDMI-0 connected 1920x1080+3600+0 (normal left inverted right x axis y axis) 527mm x 296mm
   1920x1080     60.00*+  59.94    50.00    60.05    60.00    50.04  
   1600x900      60.00  
   1280x1024     75.02    60.02  
   1280x720      60.00    59.94    50.00  
   1152x864      75.00  
   1024x768      75.03    60.00  
   800x600       75.00    60.32  
   720x576       50.00  
   720x480       59.94  
   640x480       75.00    59.94    59.93  
DP-1 connected 1920x1080+1680+0 (normal left inverted right x axis y axis) 527mm x 296mm
   1920x1080     60.00*+
   1600x900      60.00  
   1280x1024     75.02    60.02  
   1152x864      75.00  
   1024x768      75.03    60.00  
   800x600       75.00    60.32  
   640x480       75.00    59.94 

[totaam]

2019-02-02 16:09:14: stdedos commented

---

I cannot do anything to kill the server with "normal commands", it gets into some kind of unresponsive state:

$ while ! xpra stop :0 ; do sleep 1 ; done
connection timed out
timeout: server did not disconnect us
connection timed out
timeout: server did not disconnect us
connection timed out
timeout: server did not disconnect us
connection timed out
timeout: server did not disconnect us
xpra initialization error:
cannot find live server for display :0
^C
$ xpra list
Found the following xpra sessions:
/run/user/1000/xpra:
 DEAD session at :0 (cleaned up)
 LIVE session at :1
/run/xpra:
 DEAD session at :0 (cleaned up)
 LIVE session at :1

and client needs to be killed manually

[totaam]

2019-03-19 04:29:40: antoine changed owner from antoine to stdedos

[totaam]

2019-03-19 04:29:40: antoine commented

---

The offset thing belongs in a different ticket.

Timeouts in older version get a bit "easier to handle" with clipboard=no, but they don't go away.
This points towards a clipboard problem, this can only be solved properly by #812

Can you get the backtrace from a hung server? (see Debugging)

Unless I can reproduce this myself, I fear I may have to close this as 'needinfo'.

[totaam]

2019-04-04 03:29:20: antoine commented

---

#2247 is similar to this bug.

[totaam]

2019-08-27 21:41:16: stdedos changed status from new to closed

[totaam]

2019-08-27 21:41:16: stdedos set resolution to fixed

[totaam]

2019-08-27 21:41:16: stdedos commented

---

Whatever it was, it hasn't happened again