Since I switched (from WindowMaker) to KDE, emacs sometimes makes X freeze nearly completely, i.e. X does not react to any user input any more, only the mouse cursor is still shown moving.
Logging in via ssh from another machine shows that the X process takes up 100% CPU (fortunately on one of the 2 cores), the only solution is to kill X and restart it.
When starting emacs, the window is typically shown alright, the freezing seems to start more or less when the emacs window resizes to fit its current contents/ font size/ etc.
I think I also remember this bug happening once or twice when resizing e.g. a Konsole window, which, just like emacs, has a rather coarse grid of allowed sizes (only integer multiples of it character size). Maybe this may be a common cause?
Steps to Reproduce:
1. Start KDE 4
2. Start emacs.
3. If nothing happens, scroll around in emacs and/or resize its window.
The X process starts to use up 100% cpu power, thus effectively freezing the computer, except the mouse which still can be moved around.
Nothing buggy should happen.
My emerge --info:
Portage 2.2_rc62 (default/linux/amd64/10.0/desktop, gcc-4.4.3, glibc-2.11.2-r0, 2.6.34-gentoo-r1 x86_64)
System uname: Linux-2.6.34-gentoo-r1-x86_64-AMD_Athlon-tm-_X2_Dual_Core_Processor_BE-2300-with-gentoo-1.12.13
Timestamp of tree: Sun, 18 Jul 2010 09:45:02 +0000
ccache version 2.4 [enabled]
dev-lang/python: 2.6.5-r2, 3.1.2-r3
sys-devel/autoconf: 2.13, 2.65
sys-devel/automake: 1.4_p6-r1, 1.8.5-r4, 1.9.6-r3, 1.10.3, 1.11.1
CFLAGS="-O2 -pipe -march=athlon64 -msse3 "
CONFIG_PROTECT="/etc /usr/share/X11/xkb /usr/share/config /var/lib/hsqldb"
CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/env.d/java/ /etc/fonts/fonts.conf /etc/gconf /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo /etc/texmf/language.dat.d /etc/texmf/language.def.d /etc/texmf/updmap.d /etc/texmf/web2c"
CXXFLAGS="-O2 -pipe -march=athlon64 -msse3 "
FEATURES="assume-digests ccache distlocks fixpackages news noclean parallel-fetch preserve-libs protect-owned sandbox sfperms strict unmerge-logs unmerge-orphans userfetch userpriv usersandbox"
GENTOO_MIRRORS="http://de-mirror.org/distro/gentoo/ http://gentoo.supp.name/ http://gentoo.tiscali.nl/ http://gentoo.virginmedia.com/ http://gentoo.wheel.sk/ http://gentoo.mirror.pw.edu.pl/"
LINGUAS="en de es"
PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages"
PORTDIR_OVERLAY="/var/lib/layman/sunrise /var/lib/layman/java-overlay /usr/local/portage"
Unset: CPPFLAGS, CTARGET, FFLAGS, INSTALL_MASK, LC_ALL, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
It's possibly at least partly a bug in the nvidia driver (or the nvidia driver gets fed bogus data), as can be seen from these lines from Xorg.0.log correlated with the problem:
(WW) Jul 18 15:41:44 NVIDIA(0): The NVIDIA X driver has encountered too many errors. Falling
(WW) Jul 18 15:41:44 NVIDIA(0): back to legacy PCI mode.
Some camera shots of emacs before failing will follow.
Created attachment 239249 [details]
Photo of emacs' scratch buffer
This image shows a garbled emacs window. It seems as if the characters' background would access the same memory as use by KDE's panel (notice the program icons clearly visible there). I find it hard to guess if this is a cause for X freezing or maybe "just" another bug. Also I don't know if this is the fault of the Nvidia driver, KDE (maybe plasma), QT, GTK (emacs was compiled with +gtk) or emacs itself.
Could you please try with Emacs 23 and if this goes with no success with the emacs-vcs-24* ebuild?
(In reply to comment #3)
> Could you please try with Emacs 23
Which minor version of 23 did you mean? I have 23.1-r3 installed here.
> and if this goes with no success with the
> emacs-vcs-24* ebuild?
Tried it and I can't reproduce any of the errors with that version (yet). Is there any estimate how long 24 will take for the next stable release (a matter of few/many months/years)?
I'll also do more testing with emacs-vcs-24 and try to use Emacs 23 compiled without the gtk use flag.
(In reply to comment #4)
> (In reply to comment #3)
> > Could you please try with Emacs 23
> Which minor version of 23 did you mean? I have 23.1-r3 installed here.
23.2 was intended.
> > and if this goes with no success with the
> > emacs-vcs-24* ebuild?
> Tried it and I can't reproduce any of the errors with that version (yet). Is
> there any estimate how long 24 will take for the next stable release (a matter
> of few/many months/years)?
No estimate here. But it will be longer. What you can do though is run the 24 version and select it as your active main version with eselect-emacs.
> I'll also do more testing with emacs-vcs-24 and try to use Emacs 23 compiled
> without the gtk use flag.
That may be a good idea.
Some more tests and two freezes later (Alt-SysRq-... still works, fortunately) it seems that 23.2 does not help, turning off KDE compositing may be helpful, but I'll test it more. Since this bug is not always reproducible, I cannot say I'm 100% sure it can not happen with the 24 vcs version.
One more thing: Even after killing X and restarting /etc/init.d/xdm, some areas of the display are still garbled, looks like some deeper memory corruption to me.
This is extremely hard to debug as it can happen anywhere in the graphics driver, toolkit or the application itself. Do you have a garbled screen if you disable the gtk USE flag and build with motif (yes, I know it is ugly)?
(In reply to comment #7)
> Do you have a garbled screen if you
> disable the gtk USE flag and build with motif (yes, I know it is ugly)?
The complete freeze also happens with motif instead of gtk, at least with desktop compositing enabled. I'll try it without compositing the next days, maybe that will allow some conclusions.
Actually it seems as if the last time, there was a "regular" X crash, unless the following messages in Xorg.1.log.old come from shutting down the machine with the Magic SysReq keys:
[mi] EQ overflowing. The server is probably stuck in an infinite loop.
0: /usr/bin/X (xorg_backtrace+0x28) [0x49e758]
1: /usr/bin/X (mieqEnqueue+0x203) [0x49e133]
2: /usr/bin/X (xf86PostKeyEventP+0x66) [0x479276]
3: /usr/bin/X (xf86PostKeyboardEvent+0x19) [0x4792f9]
4: /usr/lib64/xorg/modules/input/evdev_drv.so (0x7fbbee6d8000+0x40d7) [0x7fbbee6dc0d7]
5: /usr/bin/X (0x400000+0x6ced7) [0x46ced7]
6: /usr/bin/X (0x400000+0x114c36) [0x514c36]
7: /lib/libpthread.so.0 (0x7fbbf371f000+0xf010) [0x7fbbf372e010]
8: /usr/lib64/xorg/modules/drivers/nvidia_drv.so (0x7fbbef420000+0x77e42) [0x7fbbef497e42]
9: /usr/lib64/xorg/modules/drivers/nvidia_drv.so (0x7fbbef420000+0xb02b9) [0x7fbbef4d02b9]
10: /usr/lib64/xorg/modules/drivers/nvidia_drv.so (0x7fbbef420000+0xb0656) [0x7fbbef4d0656]
11: /usr/lib64/xorg/modules/drivers/nvidia_drv.so (_nv002733X+0x9d) [0x7fbbef4d0c7d]
12: /usr/lib64/xorg/modules/drivers/nvidia_drv.so (_nv001056X+0x19e) [0x7fbbef498c8e]
13: /usr/lib64/xorg/modules/drivers/nvidia_drv.so (0x7fbbef420000+0xdadf6) [0x7fbbef4fadf6]
14: /usr/lib64/xorg/modules/drivers/nvidia_drv.so (0x7fbbef420000+0xdaa22) [0x7fbbef4faa22]
15: /usr/lib64/xorg/modules/drivers/nvidia_drv.so (0x7fbbef420000+0x33cfce) [0x7fbbef75cfce]
16: /usr/lib64/xorg/modules/drivers/nvidia_drv.so (0x7fbbef420000+0x340db3) [0x7fbbef760db3]
17: /usr/bin/X (0x400000+0xd413c) [0x4d413c]
18: /usr/lib64/xorg/modules/extensions/libextmod.so (0x7fbbf2122000+0xc815) [0x7fbbf212e815]
19: /usr/lib64/xorg/modules/drivers/nvidia_drv.so (0x7fbbef420000+0x2fde57) [0x7fbbef71de57]
20: /usr/bin/X (miGlyphs+0x5e6) [0x55e6e6]
21: /usr/lib64/xorg/modules/drivers/nvidia_drv.so (0x7fbbef420000+0x332473) [0x7fbbef752473]
22: /usr/bin/X (0x400000+0xd1675) [0x4d1675]
23: /usr/bin/X (0x400000+0xcbaa6) [0x4cbaa6]
24: /usr/bin/X (0x400000+0x2f634) [0x42f634]
25: /usr/bin/X (0x400000+0x2508b) [0x42508b]
26: /lib/libc.so.6 (__libc_start_main+0xfd) [0x7fbbf2571bbd]
27: /usr/bin/X (0x400000+0x24c39) [0x424c39]
It's probably better if the x11 and nvidia people have a look at this bug then.
I assume newer versions have resulted in this working since there's been no further news.