[FreeNX-kNX] Image corruption in backing store, painting errors and hang

[Mario Becroft]

I am running FreeNX on CentOS 5.2 on x86_64, and the nomachine client on
CentOS 5.2 on i386. The nx package is the one from CentOS repository;
nxclient is from nomachine. Both are version 3.2.0.

All our users have a virtual desktop that they login to, and we treat
the sessions as persistent, i.e. users never terminate the sessions, but
commonly restore their existing session on many different
terminals. Each user has exactly one session.

1. After a session has been running for a while, when a user posts and
unposts a menu, the area behind the menu sometimes becomes corrupt
(until it is redrawn). It is as if the backing store is corrupt, and the
appearance is of a bitmap with the wrong width, i.e. it contains colours
that are actually on the screen, but the scanlines are skewed and it is
hard to see what the image actually is. Once it has started happening,
the problem can come and go intermittently when you restore a session,
but is only completely fixed by terminating and restarting the session.

2. Sometimes, and I don't know if it is related to the first problem,
when running in a link speed other than lan, but especially at slower
settings such as modem and isdn, the session enters a mode where various
elements, typically window title and menu entry text, and the background
of menus and some other windows, are not painted. However the icons
beside each menu entry appear normally. It seems to be connected with
the deferred drawing mechanism that occurs on the slower link
settings. Once it has started happening, this problem persists until you
terminate and restart the session.

3. Sometimes, the user's session will stop responding entirely. Their
nxclient reports a loss of connection, and they cannot resume the
session again. nxagent is consuming 100% CPU. This problem seems to be
correlated with use of vmware workstation within the nx session, but we
are not certain about whether it happens only when running vmware. The
only way to unhang it is to terminate and restart the session.

4. A less critical issue, but perhaps related: our terminals' window
managers are configured to resize the nxclient window to fill the screen
the moment it is created. Thus, when users login to different terminals,
their session gets resized to the terminals' various screen sizes. This
works fine, except for one weird behaviour. If a user logs in and the
screen size is changed, their session often becomes very slow. Only
certain things appear slow. gnome-terminal is a good example: normally,
scrolling the terminal by dragging the scrollbar thumb up and down is
quite fast, but in the faulty mode, it scrolls at only about 2 fps. I
carefully observed the traffic volume and noted that in the good and
faulty modes, the amount of traffic on the wire for scrolling the
terminal a certain number of pages is the same. So there is no increase
in the amount of data involved in the faulty mode. But in the faulty
mode, the X server on the terminal is at 100% CPU during the scrolling,
whereas normally it is at only about 50%. Logging out of the session
then restoring the session (not restarting it) fixes the
problem. Changing the client to "full screen" mode with control-alt-T,
and changing back (which does not actually change the screen size, since
it already fills the screen anyway), also fixes the problem. Note: this
does not happen any time that you resize the session. Only when it is
resized immediately after the nxclient window is created. Logging in and
leaving the window at its current size, then later resizing it, works
fine.

Problems 1 to 3 are only solved by terminating and restarting the user's
session. Problem 4 goes away next time you restore the session (provided
you do not try immediately to resize it).

All our users run gnome, restore their sessions to various different
terminals and often resize the screen.

I personally use the same setup but I run fvwm, I don't use any of the
gnome software, and I seldom resize my screen or login on different
terminals. I have never seen any of the above problems. So perhaps the
problems are triggered by gnome, or resizing the screen.

The backing store issue is the most obviously apparent problem and seems
to happen generally before any of the other problems. I wondered whether
some memory corruption could be happening inside nxagent when the
backing store goes wrong, triggering the other problems. Or maybe the
backing store issue is only a symptom.

I tried to disable the backing store, but changing the backing store
setting in the nxclient has no effect. I had to add
AGENT_EXTRA_OPTIONS_X="-bs" to node.conf to really turn it off. I don't
know yet whether this will fix any of the problems.

This report is rather long, I know. I hope someone else has seen at
least one of these problems, and if so, we could compare notes.

Any help will be greatly appreciated!

-- 
Mario Becroft <mb at gem.win.co.nz>