Slow performance with remote X applications (java, firefox/xul, etc.)

I've submitted this bug as https://bugs.freedesktop.org/show_bug.cgi?id=17868 as well. Though the problem may not be in ia32-libs -package, it contains the /usr/lib32/libX11.so.6.2.0 library that appears to be somehow relevant to the problem at hand.

Some Java applications, such as the trial version in http://www.typingmaster.com/, run unusably slow when used over a remote X connection.

I'm using Ubuntu Hardy 8.04.1 with LTSP5, Linux kernel 2.6.24-19-server, with 32-bit firefox and 32-bit Java-plugin. The relevant package versions are here:

firefox32 2.0.0.17
sun-java32 1.6.0.5
sun-java6-jre 6-06-0ubuntu1
ia32-libs 2.2ubuntu11

The issue does not appear to be Java-version related (it exists in 1.5 and 1.6 versions). I have not tested the very latest Java-versions though. The reason I'm reporting this as a possible XCB-related issue is that one can workaround the problem by using an X11-library that does not link to XCB.

In current Ubuntu version (Hardy), /usr/lib32/libX11.so.6.2.0 library links to /usr/lib32/libxcb-xlib.so.0 and /usr/lib32/libxcb.so.1 libraries, XCB version is 1.1. In previous Ubuntu version (Gutsy) the X11-library does not do this. When the new library shared object replaced with the old one, the problem disappears, and Java applications that had problems run fine.

There may be some other differences between the X11-libraries, but using XCB as an underlying implementation seems to be a major change, or is it? All other applications do not appear to have these problems, Java applications appear to be the sole source of these problems.

I'm adding two attachments that show tshark-dump of network traffic in both cases, perhaps it helps to analyze the issue. What happens there is one keypress on typingmaster Java-version, on Hardy/XCB case it takes half a minute to process one keypress and switch a screen, on Gutsy/no-XCB case it takes maybe a second.

Juha

Juha, I think I'm seeing a similar problem here, but with slow typing within OpenOffice.org. I was wondering, do you replace the library in BOTH the thin client chroot, and on the server, or only on the server?

@Scott:
I asked Juha how to apply the workaround, here is his answer. #4 is the answer you are asking for:

> 1.) How can a single file be replaced between different Ubuntu versions?

Simply replacing the file (with cp) should be enough, but in
case updates should happen to ia32-libs package that contains the
/usr/lib32/libX11.so.6.2.0 file, those updates will overwrite the
changed file. dpkg-divert can be used to solve this problem, it can
be used to divert file updates to another place (in this case, because
the file is a shared library, it should not be in the same directory,
otherwise ldconfig will link to the wrong file).

You might want to test by simply installing the gutsy version of
ia32-libs package, it should work, but I don't recommend that as a
permanent solution (it will change many other libraries as well).

> 2.) Where can I get the file from Gutsy?

http://packages.ubuntu.com/gutsy-updates/amd64/ia32-libs/download

You can unpack deb-archives with (IIRC):

(mkdir tmp && cd tmp && ar x ../ia32-libs_2.1ubuntu4_amd64.deb && \
   tar -zxf data.tar.gz)

You'll find the file there.

   Comment: That is for arch amd64.
   For arch i386 you'll find the package here:
   http://packages.ubuntu.com/gutsy/libx11-6

> 3.) Are there side effects that probably can affect the system?

Perhaps, but I'm not aware of any.

> 4.) Am I right that the file needs to be replaced in the ltsp chroot?

No, X-clients use this library, so it needs to be replaced in the ltsp
server environment, NOT in the image that is served to terminals.

I hope this helps.

Juha

I can confirm this bug on Ubuntu 8.04.1 LTS running with LTSP5.

I can also confirm the fix of replacing the Hardy version of:

/usr/lib/libxcb-xlib.so.0

With the Gutsy version, as described in above comment. I have performed this fix on 2 separate LTSP networks and it seems to work fine, with no ill effects. The problem definitely lies in the changes made in the Hardy version of said file (linking to XCB? Not sure.)

Change package from ia32-libs to libxcb-xlib0 (as this is what is installed, by default on an i386 system).

I had observed on our LTSP5 server whit ubuntu intrepid:
- a java-application start on a thin-client is very slow.
- the same java-application start with a nomachine-client nx works fast.
why?

Yikes.. libxcb priority is "Low" ? That's surprising, given that (presumably) because of libxcb, Java applications are pretty much unusable in LTSP environments.

This is a showstopper at our school, too. It's not possible to use geogebra.
Thank god, the above solution "works" for us!

[This is an automated message]

Hi juha-erkkila,

Please attach the output of `lspci -vvnn` too.

It seems as though even using 'dpkg-divert' won't help in this case, as ldconfig seems to override the libX11.so.6 symlink whenever changes take place.

man dpkg-divert:
---
Care should be taken when diverting shared libraries, ldconfig(8) creates a symbolic link based on the DT_SONAME field embedded in the library. Because ldconfig doesn’t honour diverts (only dpkg does), the symlink may end up pointing at the diverted library, if a diverted library has the same SONAME as the undiverted one.
---

Anyway, I keep replacing the symlink, but it seems as though whenever I perform Ubuntu updates, the libX11.so.6 symlink reverts and points to the original file (which I renamed to libX11.so.6.2.0.orig). It's EXTREMELY frustrating, especially when administrating multiple servers that all experience this issue (7 in my case). It's not clean to replace this file all the time, either, as if people are logged onto thin clients when you replace it, they crash outright.

Could this bug report be more effective if it points to 'libx11-6' ? See below:

jerickson@Fibonacci:~$ apt-file search libX11.so.6
libx11-6: /usr/lib/libX11.so.6
libx11-6: /usr/lib/libX11.so.6.2.0

Sincerely,
Jordan/Lns

Hope this is an accurate affecting package change:

$ apt-file search libX11.so.6
libx11-6: /usr/lib/libX11.so.6
libx11-6: /usr/lib/libX11.so.6.2.0

Jordan,
I checked our system about changing symbolic links to libX11.so.6.2.0. by the update process, but I can confirm your issue only partly. When I inspected our system I found libX11.so.6 pointing to the wrong (hardy) version. I am not sure, if this link was set by an update process of if I just forgot to set it to the gutsy version when i installed the gutsy file. Therefore I proved as follows:

I renamed the original hardy file to
libX11.so.6.2.0.hardy
and copied the gutsy libX11.so.6.2.0 to
libX11.so.6.2.0.gutsy

Additionally I changed the symbolic links:
libX11.so.6 -> libX11.so.6.2.0.gutsy
libX11.so.6.2 -> libX11.so.6.2.0.gutsy

After sudo apt-get update and sudo apt-get upgrade the links still remain as I set them:

wollw@harry:/usr/lib$ ls -l libX11.*
lrwxrwxrwx 1 root root 21 2009-01-15 10:54 libX11.so.6 -> libX11.so.6.2.0.gutsy
lrwxrwxrwx 1 root root 21 2009-01-15 10:53 libX11.so.6.2 -> libX11.so.6.2.0.gutsy
-rw-r--r-- 1 root root 986540 2008-11-01 14:34 libX11.so.6.2.0.gutsy
-rw-r--r-- 1 root root 944876 2008-03-11 21:33 libX11.so.6.2.0.hardy

By the next apt-get upgrade the link was unfortunately changed:

wollw@hermine:/usr/lib$ ls -l libX11.*
lrwxrwxrwx 1 root root 21 2009-01-15 12:22 libX11.so.6 -> libX11.so.6.2.0.hardy
lrwxrwxrwx 1 root root 21 2009-01-15 12:20 libX11.so.6.2 -> libX11.so.6.2.0.gutsy
-rw-r--r-- 1 root root 986540 2008-11-03 11:47 libX11.so.6.2.0.gutsy
-rw-r--r-- 1 root root 944876 2008-11-03 11:47 libX11.so.6.2.0.hardy

I guess it depends on the packages involved in the upgrade process whether the link is changed or not.
Is there no way to prevent this?

Not that I know of - but that, IMHO, is moot - we need to get the core issue fixed and not waste time and resources trying to find the best, most stable workaround. If I have to put on an LTSP cheerleader uniform, I will! ;)

To use an older version of libX11, I would suggest to unpack it in
a different place, and use the LD_LIBRARY_PATH environment veriable
to point your executables to that place. That way, you don't have
to fight the package system.

For example:

dpkg-deb -x ~//libx11-6_1.1.1-1ubuntu4_amd64.deb /usr/local/foo/libx11-6-6_1.1.1-1ubuntu4_amd64
export LD_LIBRARY_PATH=/usr/local/foo/libx11-6-6_1.1.1-1ubuntu4_amd64/usr/lib:${LD_LIBRARY_PATH}

Vincent.

Please see http://www.typingmaster.com/forum/messages.aspx?TopicID=11 for information regarding a specific case of this bug, in the TypingMaster java-based typing tutor for Linux. This is the app that I have the most issues with regarding this bug, and the people at TypingMaster have been very helpful so far. Hopefully they can be a good resource to help get this thing fixed once and for all.

Confirmed on Jaunty with the following test case:

 - Close all your firefox
 - ssh -Y localhost (requires a running ssh server)
 - firefox
 - right click, it'll take around 3s ...

Bug 305531 is another instance of this bug

I agree on fixing the root cause, but for now, a workable workaround is the following:

- Download the gutsy version (libx11-6_1.1.1-1ubuntu4_i386.deb)
# dpkg -i libx11-6_1.1.1-1ubuntu4_i386.deb
# echo libx11-6 hold |dpkg --set-selections

Leave the libx11-6 on hold until there is a real fix for the problem.

This work around is supposed to correct the issue with Context menus correct? I attempted to do this and it did not correct the problem. Any ideas?

Hi Guys,

 I think that my problem is related with this issue. I have a LTSP environment and when my clients access my web based application with Firefox, all comboboxes in any form take almost 2 sec to drop down the options.
In Opera browser the performance is ok.

To reproduce is simple:

1) Save the following html file in any accessible place:

<html>
<body>
<form method="post" action="test.php">
Languages:<p>
<select name="combolang"><option value="python">Python</option>
<option value="php">PHP</option>
<option value="cplus">C++</option>
<option value="pascal">Pascal</option>
<option value="asm">Assembly</option>
<option value="java">Java</option>
</select>
</form>
</body>
</html>

2)Open the html in Firefox over a XDMCP connection, click in the combo and you will see how slow this is.

My LTSP Server: Xubuntu 8.10
$ lsb_release -rd
Description: Ubuntu 8.10
Release: 8.10

$ apt-cache policy firefox
firefox:
  Instalado: 3.0.7+nobinonly-0ubuntu0.8.10.1
  Candidato: 3.0.8+nobinonly-0ubuntu0.8.10.2
  Tabela de versão:
     3.0.8+nobinonly-0ubuntu0.8.10.2 0
        500 http://archive.ubuntu.com intrepid-updates/main Packages
        500 http://archive.ubuntu.com intrepid-security/main Packages
 *** 3.0.7+nobinonly-0ubuntu0.8.10.1 0
        100 /var/lib/dpkg/status
     3.0.3+nobinonly-0ubuntu2 0
        500 http://archive.ubuntu.com intrepid/main Packages

We will have a fix for this?? This issue is very important...

Try the proposed workaround above.

https://bugs.launchpad.net/ubuntu/+source/libxcb/+bug/277069/comments/22

Since I applied the workaround, I am not able to activate the desktop effects any more.

for the command:

$compiz --replace

Checking for Xgl: not present.
Detected PCI ID for VGA:
Checking for texture_from_pixmap: present.
Checking for non power of two support: present.
Checking for Composite extension: present.
Comparing resolution (1280x1024) to maximum 3D texture size (4096): Passed.
Checking for Software Rasterizer: Not present.
Checking for nVidia: present.
Checking for FBConfig: present.
Checking for Xgl: not present.
Segmentation fault

Does anyone know why this is not working any more?

Thanks a lot, Stephan.

Thought i'd just comment that I posted a potential solution to the bug at the freedesktop bug report mentioned earlier. It's a small patch and if verified could be a point in debian picking up and backporting to affected systems.

@eluplus, THANK YOU

I have patched intrepid & jaunty, both i386 and amd64 and it works BEAUTIFULLY... This is one reason why I love open source.. Again, a big Thank You to elupus.

If there is anything I can do to help further, please let me know.

Shri
PS: intrepid required manual patching as the code is different in xcb_util.c I can provide a patch file if required...

I don't suppose an 8.04 PPA/package would be in order? This would help me IMMENSELY. I've got multiple sites with the exact same issue and a pre-packaged Hardy fix would rock my socks off! I have 7 sites I can test the fix out on if that helps.

Do you provide a DEB-package for jaunty amd64? It could be useful for us.
Thank you

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I have built a fixed package for Jaunty in my PPA:
https://launchpad.net/~stgraber/+archive

Tested it with Jaunty i386 and amd64, both works fine.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkoWuq0ACgkQjxyfqkjBhuxBIwCfUHLXYXHXzGcWWWSSCzlAV1EQ
s98AnjseVqD4H1r8RA74klGaJpAeoekK
=Ho65
-----END PGP SIGNATURE-----

Thank you!!! It works great. :-)

As Jordan mentioned it is very needed to get this bug fixed in the last long term version 8.04. There are many schools and other LTSP users working with hardy who affected by this bug. We cannot upgrade as LTSP still is buggy in versions newer than hardy.

I put up a patched package for hardy in my ppa: https://launchpad.net/~abeld/+archive/ppa (The libxcb packages). (I simply applied the same patch that Stéphane Graber did to the hardy version of libxcb.)

(The changelog entry is a bit wrong: it should read "Add 200_ubuntu_bug_no_277069_fix.diff, ...".)

The previous debdiffs were done based on the patch from freedesktop's bug tracker.
I test built the jaunty one (in my PPA) and uploaded the others too (still building) to make sure they build fine.

The patch for hardy and intrepid is slightly different from the one for jaunty and karmic. I also had to add a patching system for intrepid, jaunty and karmic, I used quilt as it was the one used for hardy (so reducing the changes between the debdiffs).

Stephane, the patches look good, but could you please include a more detailed description in the changelog? For technical folk like us, knowing it disables Nagle's algorithm is probably sufficient, but for end users the changelog should describe a) symptoms of the problems it solves, b) how it solves it, and c) any mention of potential regressions that could result. 2-3 sentences is probably sufficient.

Meanwhile, I've uploaded the karmic debdiff so we can get some preliminary testing done on the patch. If that goes well, and if you can update the changelogs for the older releases, then sruing them into the earlier patches can be tried.

This bug was fixed in the package libxcb - 1.2-1ubuntu2

---------------
libxcb (1.2-1ubuntu2) karmic; urgency=low

  * Disable Nagle on TCP socket (LP: #277069)

 -- Stephane Graber <email address hidden> Wed, 27 May 2009 01:31:03 +0200

[The libxcb task is sufficient for purposes of this bug]

Tested Stéphane's libxcb PPA's packages on Jaunty, on two different machines
- thinkpad X41 with Jaunty32bits , with 00:02.0 VGA compatible controller: Intel Corporation Mobile 915GM/GMS/910GML Express Graphics Controller (rev 03)
- HP Pavilion a1610n AMD64x2 on Jaunty 64bits with 00:05.0 VGA compatible controller: nVidia Corporation C51 [GeForce 6150 LE] (rev a2)

No problem up to now, everything works well both locally and remotely.

I confirm this working under Jaunty.
VERY WELL DONE!

Tested Stéphane's libxcb PPA's packages on Jaunty
connected to Jaunty from Windows clients Xming and Cygwin/X

problem still present..

On AMD64
Openproj / java : OK
Acroread : slow
Google-earth : not usable

I really wonder how this managed to slip the jaunty update of libxcb today.... it's a simple bugfix that was accepted directly upstream. And it renders jaunty and intrepid unusable for remote X.

Simon, Andrea:

And you have verified that the performance was good on gutsy? Cause java have a tendency to require a huge amount of data transfers. Running java over ssh for example is often quite horrible.

Regarding the last pieces of getting this bug fixed in Karmic, I don't have a working amd64 system right now, but I've prepared https://launchpad.net/~cjwatson/+archive/ia32-libs-testing which should include the libxcb fix for this bug. I'd really appreciate it if any Karmic amd64 users could install ia32-libs from that test archive and confirm whether it fixes this bug.

(I can't speak for what's going on with Jaunty ...)

This bug was fixed in the package ia32-libs - 2.7ubuntu7

---------------
ia32-libs (2.7ubuntu7) karmic; urgency=low

  * Update sources.list.deb for karmic.
  * Revert gtk+2.0 change from 2.7ubuntu6, as the underlying bug was fixed
    in gtk+2.0 2.16.1-0ubuntu3.
  * fetch-and-build:
    - Add pulseaudio, since libpulsecore moved there.
    - Drop libcap1, which is now obsolete.
    - Replace libdirectfb-1.0-0 with libdirectfb-1.2-0.
    - Replace libkrb53 with libgssapi-krb5-2, libk5crypto3, libkrb5-3, and
      libkrb5support0.
    - Replace gcc-4.3-base with gcc-4.4-base.
    - Replace python2.5 with libpython2.6.
    - Replace libdb4.6 with libdb4.7.
    - Add libvorbisenc2 for libsndfile1/pulseaudio/pulseaudio-utils.
    - Add libv4l-0 for libsane (but just depend on lib32v4l-0 on amd64).
    - Add libudev0 for pulseaudio.
  * Depend on lib32asound2-plugins on amd64 instead of shipping it (LP:
    #305860).
  * Depend on lib32bz2-1.0 on amd64 instead of shipping it.
  * Freshen packages (LP: #277069, #389510, #393503).

 -- Colin Watson <email address hidden> Fri, 17 Jul 2009 15:20:02 +0000

Hello!

In our company we use Ubuntu Hardy as development platform. We have chosen Ubuntu Hardy because of the long term support. Unfortunately we discovered the same problem in context with Eclipse, which is started remote. We would highly appreciate, if this bug could also be fixed in Hardy LTS with high importance.

Thanks in advance,
Johannes Kogler

Stéphane Graber

Status of our libxcb:
dpkg -l | grep libxcb
ii libxcb-xlib0 1.1-1ubuntu2~ppa1 X C Binding, Xlib/XCB interface library
ii libxcb1 1.1-1ubuntu2~ppa1 X C Binding

As we are still waiting for getting an update for hardy I tried to build libxcb (i386) from your last hardy.debdiff.
(I tried to apply the patch as described at https://wiki.ubuntu.com/UbuntuPackagingGuide/BuildFromDebdiff)

cd libxcb-1.1 && patch -p1 < ../hardy.debdiff
patching file debian/patches/series
patching file debian/changelog
Hunk #1 FAILED at 1.
1 out of 1 hunk FAILED -- saving rejects to file debian/changelog.rej
patching file debian/patches/101_fix_lp277069.diff

Any hint how to get the rejected patch fixed? This error does not occur on another server with amd64 System.

TIA

if I got it right libxcb1 1.1-1ubuntu2~ppa1 does include the patch. But users are still complaining slow performance with Gimp, Netbeans, Eclipse on remote X

Any news on when Jaunty will get this fix?

Intrepid Ibex reached end-of-life on 30 April 2010 so I am closing the report. The bug has been fixed in newer releases of Ubuntu.

Nice work - ignore it until end-of-life.

Jaunty reached end-of-life on 23 October 2010, so this bug will not be fixed in that version of Ubuntu. It has been fixed in newer versions.

Hardy has seen the end of its life and is no longer receiving any updates. Marking the Hardy task for this ticket as "Won't Fix".