Details are available here:
The summary is of the symptoms is that the keyboard occasionally locks up completely, with no response even to NumLock or CapsLock. The mouse pointer tracks, but mouse button events are ignored. The only way to recover the system from the console is to reset or power cycle, but the system itself is still up and will respond to ssh connections. Underneath, the X server is consuming 100% of the CPU. The triggering event is usually an attempt to open a menu in any of the OpenOffice applications, but I've personally seen the same condition triggered by GoogleEarth and Dosemu.
There seems to be no commonality of hardware (at least x86 and amd64), distribution (I'm on Gentoo, but bug reports are common on Debian, Ubuntu and Suse among others), Xorg server version (I've personally witnessed at least x11-base/xorg-server-1.1.1-r4 through 220.127.116.11-r1), video card (at least Nvidia and Intel), kernel version (in my case from 2.6.19.something through 18.104.22.168, the most recent vanilla-sources kernel at the moment) or anything else I can think of offhand.
This is almost certainly an upstream problem. A patch is available here:
...but this patch is not incorporated into the upstream release of version 1.4, at least not as of this writing (2007/10/25).
Basically I'm just requesting that this patch or something like it be incorporated into the next ebuild for x11-base/xorg-server
Steps to Reproduce:
Basically the only way I've found to reproduce this is to keep using OpenOffice. The length of time may vary (from a low of a few hours to a high of about three weeks of using OpenOffice 3-4 times per week), but sooner or later the system will lock up when clicking on a pulldown menu in OpenOffice.
As above, the system will enter the state in which the X server is consuming all available CPU cycles and the keyboard is completely unresponsive.
Some people have reported that their systems returned to normal eventually with no intervention (where "eventually" is on the order of 5-30 minutes), but in my experience if the machine hangs at night, it will still be hung until the next morning when I can log into it remotely.
The system shouldn't lock up this way. :-)
My personal configuration is an Asus P5B-VM motherboard with an Intel Core 2 Q6600 CPU, onboard Intel X3000 (965G) graphics, 4 Gb of memory, 32-bit (x86) Gentoo with vanilla-sources kernel 22.214.171.124. However, as described above, the problem appears not to be specific to any of these details; the same problem has been reported on systems that vary in all of the above respects.
Same issue here, in both openoffice and openoffice-bin. Opening any openoffice menu has a 25% chance of freezing X.
Portage 126.96.36.199 (default-linux/amd64/2007.0/desktop, gcc-4.2.2, glibc-2.6.1-r0, 2.6.22-gentoo-r8 x86_64)
System uname: 2.6.22-gentoo-r8 x86_64 Intel(R) Core(TM)2 CPU 6600 @ 2.40GHz
It's on master branch, but it hasn't yet 1.4 branch yet. I asked ajax about that, and I'm waiting to hear back.
Author: Adam Jackson <email@example.com>
Date: Tue Sep 11 11:37:06 2007 -0400
Ignore - not just block - SIGALRM around Popen()/Pclose().
Because our "popen" implementation uses stdio, and because nobody's stdio
library is capable of surviving signals, we need to make absolutely sure
that we hide the SIGALRM from the smart scheduler. Otherwise, when you
open a menu in openoffice, and it recompiles XKB to deal with the
accelerators, and you popen xkbcomp because we suck, then the scheduler
will tell you you're taking forever doing something stupid, and the
wait() code will get confused, and input will hang and your CPU usage
slams to 100%. Down, not across.
Should be fixed in 188.8.131.52, please reopen if it's not.
I added this in /etc/portage/package.keywords:
# not asked by portage but required
emerge --sync and emerge -u xorg-server
revdep-rebuild -i -p shows only gobby which fails to compile (another bug)
The behaviour is the same as 184.108.40.206-r5: I can run X, alone, but starting gdm, xdm or slim locks the keyboard, mouse and X (100% CPU) cannot be killed.
Portage 220.127.116.11 (default/linux/x86/2008.0/desktop, gcc-4.1.2, glibc-2.6.1-r0, 2.6.24-gentoo-r3 i686)
System uname: 2.6.24-gentoo-r3 i686 AMD Athlon(tm) XP 2600+
Timestamp of tree: Mon, 14 Apr 2008 20:04:01 +0000
distcc 2.18.3 i686-pc-linux-gnu (protocols 1 and 2) (default port 3632) [disabled]
ccache version 2.4 [enabled]
dev-java/java-config: 1.3.7, 2.1.4
dev-lang/python: 2.3.5-r3, 2.4.4-r9
sys-devel/autoconf: 2.13, 2.61-r1
sys-devel/automake: 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10.1
CFLAGS="-march=athlon-xp -O2 -pipe -fomit-frame-pointer"
CONFIG_PROTECT="/etc /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/share/config /var/bind"
CONFIG_PROTECT_MASK="/etc/env.d /etc/env.d/java/ /etc/fonts/fonts.conf /etc/gconf /etc/php/apache2-php5/ext-active/ /etc/php/cgi-php5/ext-active/ /etc/php/cli-php5/ext-active/ /etc/revdep-rebuild /etc/terminfo /etc/texmf/web2c /etc/udev/rules.d"
CXXFLAGS="-march=athlon-xp -O2 -pipe -fomit-frame-pointer"
FEATURES="ccache distlocks fixpackages metadata-transfer parallel-fetch sandbox sfperms strict unmerge-orphans userfetch"
GENTOO_MIRRORS="http://www.gtlib.gatech.edu/pub/gentoo http://mirror.datapipe.net/gentoo http://gentoo.mirrors.pair.com/"
PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages"
Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LDFLAGS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, PORTDIR_OVERLAY
I'll try recompile everything with stable version
Created attachment 151747 [details, diff]
patch using sigaction instead of signal (no glibc-only extensions)
Type sighandler_t and function signal() are glibc extensions and as such do not work on systems without glibc (for instance, Darwin/OS X). This patch uses POSIX signal-handling functions and structs instead, for cross-platform compatibility.
(In reply to comment #5)
> Created an attachment (id=151747) 
> patch using sigaction instead of signal (no glibc-only extensions)
> Type sighandler_t and function signal() are glibc extensions and as such do not
> work on systems without glibc (for instance, Darwin/OS X). This patch uses
> POSIX signal-handling functions and structs instead, for cross-platform
Apologies for not knowing where to put this patch/the correct format/etc. It's Adam Jackson's patch, updated to use the POSIX sighandlers instead.
I forgot to mention that rebuilding system/world worked for me. But that takes a loooong time!
(In reply to comment #6)
> (In reply to comment #5)
> > Created an attachment (id=151747) 
> > patch using sigaction instead of signal (no glibc-only extensions)
> > Type sighandler_t and function signal() are glibc extensions and as such do not
> > work on systems without glibc (for instance, Darwin/OS X). This patch uses
> > POSIX signal-handling functions and structs instead, for cross-platform
> > compatibility.
> Apologies for not knowing where to put this patch/the correct format/etc. It's
> Adam Jackson's patch, updated to use the POSIX sighandlers instead.
It needs to go upstream to bugs.freedesktop.org in the xorg product. You can get the latest copy of the xserver source to patch against by running `git clone git://anongit.freedesktop.org/git/xorg/xserver`.