Xpra: Ticket #63: window contents is not drawn at all

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

Mon, 02 Jan 2012 14:12:27 GMT - Antoine Martin: owner, status, description changed

Mon, 02 Jan 2012 14:13:12 GMT - Antoine Martin:

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..

Mon, 02 Jan 2012 14:19:24 GMT - Antoine Martin:

Does reverting r313 help?

Does commenting this line out help:

#self._models[model].shown = True

Mon, 02 Jan 2012 14:33:17 GMT - Antoine Martin:

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?

Mon, 02 Jan 2012 15:34:29 GMT - Timo Juhani Lindfors:

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.

Mon, 02 Jan 2012 15:38:14 GMT - Antoine Martin: description changed

Tue, 03 Jan 2012 12:09:29 GMT - Timo Juhani Lindfors:

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.

Tue, 03 Jan 2012 12:34:44 GMT - Antoine Martin:

the bitness thing reminds me of #40 and this changeset: r275

Does reverting it fix things?

Tue, 03 Jan 2012 12:40:31 GMT - Antoine Martin:

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.

Wed, 04 Jan 2012 13:47:27 GMT - Antoine Martin: status changed; resolution set

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 release.

Wed, 04 Jan 2012 21:02:55 GMT - Antoine Martin:

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.

Mon, 20 Feb 2012 19:26:50 GMT - Antoine Martin: milestone changed; version set

Sat, 23 Jan 2021 04:44:31 GMT - migration script:

this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/63