#63 closed defect (fixed)
window contents is not drawn at all
Reported by: | Timo Juhani Lindfors | Owned by: | Antoine Martin |
---|---|---|---|
Priority: | major | Milestone: | 0.0.7.x |
Component: | client | Version: | 0.0.7.34 |
Keywords: | Cc: |
Description (last modified by )
I've upgraded from svn r266 to r377 and all my windows are just filled with black background. window titles are correct and so are application icons.
bad svn revs bisected to r313 (good) r315 (bad), r314 can be ignored (non code)
note: even with 313 I sometimes see areas that are just not updated and only show black
Change History (13)
comment:1 Changed 10 years ago by
Description: | modified (diff) |
---|---|
Owner: | changed from Antoine Martin to Antoine Martin |
Status: | new → accepted |
comment:2 Changed 10 years ago by
comment:3 Changed 10 years ago by
comment:4 Changed 10 years ago by
Also, I would expect to see some errors or at least messages in the log, does minimizing+maximizing help? How about resizing them?
Judging from the earlier work on #48, this is likely to be triggered by the client's window manager doing odd things (like unmapping windows), which one do you use?
comment:5 Changed 10 years ago by
Here's again the info that I mentioned in the initial description:
<lindi-> svn 304 good
<lindi-> svn 337 bad
<lindi-> 320 bad
<lindi-> 312 good
<lindi-> 316 bad
<lindi-> 313 good
<lindi-> 315 bad
<lindi-> hmm, even with 313 I sometimes see areas that are just not
updated and only show black
client: debian squeeze i386 with gnome and metacity.
server: debian squeeze amd64.
gnome-terminal and iceweasel both show the problem. resizing does not help.
comment:6 Changed 10 years ago by
Description: | modified (diff) |
---|
comment:7 Changed 10 years ago by
The bug does not occur if I run the client on a 64-bit laptop.
The bug does occur if I run the client on another 32-bit desktop.
comment:8 Changed 10 years ago by
comment:9 Changed 10 years ago by
Problem has been identified as being the use of mmap memory transfers when the home directory is shared via an NFS mount. --disable-mmap
works around this problem.
We need to detect this case and turn off mmap transfers.
comment:10 Changed 10 years ago by
Resolution: | → fixed |
---|---|
Status: | accepted → closed |
r390 uses $TMPDIR (or /tmp) as the location for the mmap file, this is never shared between machines so it should be safe to use.
However, since /tmp is public, there is now a possible race where an attacker can wait for the mmap file to appear and quickly create it on the server before it receives the "hello" packet... the server will then use this file and send pixel data to the attacker. Will fix before the 0.0.7.33
release.
comment:11 Changed 10 years ago by
r395 ensures that we will never use an mmap area unless we can verify that it is the one the client created: the client places a 16 byte random token in the file and we verify it is present server-side.
comment:12 Changed 10 years ago by
Milestone: | current → 0.0.7.x |
---|---|
Version: | → 0.0.7.34 |
comment:13 Changed 16 months ago by
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/63
Please specify steps to reproduce since I obviously have never seen this anywhere: client/server os, client/server xpra versions, example application to run (xterm?) etc..