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
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..
Does reverting r313 help?
Does commenting this line out help:
#self._models[model].shown = True
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?
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.
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.
the bitness thing reminds me of #40 and this changeset: r275
Does reverting it fix things?
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.
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.
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.
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/63