Package: emacs23-lucid Version: 23.3+1-4 Severity: important I am in an utf8 environment ($LANG=$LC_MESSAGES=en_AU.UTF-8") with default emacs settings as far as encodings are concerned. I've reproduced this on both lucid and gtk, and with pretty minimal elisp init config.
If I use xcb (specifically, "xcb -S 0 ; xcb -p 0"), to populate the first X cut buffer with a UTF8 string tagged as such (eg, select "‽?", then run those xcb commands), then emacs tries to chew 100% CPU next time you try to kill/yank/do anything with the cut buffer (and sometimes, just leaving it overnight - perhaps some function called by the idle loop - I thought I had implicated font-lock at some point in time during testing). This bug has been around since emacs21 in various guises. When I previously looked into it, it actually caused emacs to crash with: "X protocol error: BadMatch (invalid parameter attributes) on protocol request 18", (eg: https://bugs.launchpad.net/ubuntu/+source/emacs-snapshot/+bug/369839 , which claims "This is caused by an application (xcb) adding UTF8_STRING typed cut buffer properties. Emacs attempts to rotate such properties and fails.") and someone had posted show_type.c and reset_type.c: ===================== > cat bin/show_type.c #include <stdio.h> #include <stdlib.h> #include <X11/Xlib.h> #include <X11/Xatom.h> int main() { Display *dpy; Window window; int i; Atom type_r; int format_r; unsigned long nitems_r, bytes_after_r; unsigned char *prop_r; dpy = XOpenDisplay(NULL); window = RootWindow(dpy, 0); for (i = 9; i < 17; i++) { printf("i = %d", i); XGetWindowProperty(dpy, window, (Atom)i, 0, 4, False, XA_STRING, &type_r, &format_r, &nitems_r, &bytes_after_r, &prop_r); printf(" type = %d format = %d str = %s\n", type_r, format_r, XGetAtomName(dpy, type_r)); } exit(0); } ===================== ===================== > cat bin/reset_type.c #include <stdio.h> #include <stdlib.h> #include <X11/Xlib.h> #include <X11/Xatom.h> int main() { Display *dpy; Window window; int i; unsigned char *data = ""; dpy = XOpenDisplay(NULL); window = RootWindow(dpy, 0); for (i = 9; i < 17; i++) { printf("i = %d\n", i); XChangeProperty(dpy, window, (Atom)i, XA_STRING, 8, PropModeReplace, data, 0); } XFlush(dpy); exit(0); } ===================== If showtype returned anything to do with UTF8: > ./show_type i = 9 type = 346 format = 8 str = UTF8_STRING i = 10 type = 31 format = 8 str = STRING i = 11 type = 31 format = 8 str = STRING i = 12 type = 31 format = 8 str = STRING i = 13 type = 31 format = 8 str = STRING i = 14 type = 31 format = 8 str = STRING i = 15 type = 31 format = 8 str = STRING i = 16 type = 31 format = 8 str = STRING then the next C-k kill in emacs would cause it to lockup. If you then ran reset_type ; show_type: > ./reset_type ; ./show_type i = 9 i = 10 i = 11 i = 12 i = 13 i = 14 i = 15 i = 16 i = 9 type = 31 format = 8 str = STRING i = 10 type = 31 format = 8 str = STRING i = 11 type = 31 format = 8 str = STRING i = 12 type = 31 format = 8 str = STRING i = 13 type = 31 format = 8 str = STRING i = 14 type = 31 format = 8 str = STRING i = 15 type = 31 format = 8 str = STRING i = 16 type = 31 format = 8 str = STRING then a restarted emacs would function fine. So, what's emacs not liking about UTF8_STRING? Lots of hits on the web of this working for people, but the defaults haven't been working for me for years! Note, that I still see this even with a very minimal elisp init configuration, so I doubt it's my ported files from XEmacs (I'm a recent XEmacs refugee, trying finally to overcome the hurdles I've had with emacs in the past years whenever I've tried to switch back). Yes, I know about the debug steps that have been posted elsewhere, but first I have to find the time to recompile emacs with debugging symbols. Can't we just have a -debug package instead? -- System Information: Debian Release: wheezy/sid APT prefers oldstable APT policy: (500, 'oldstable'), (500, 'stable'), (5, 'testing'), (1, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.39-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages emacs23-lucid depends on: ii emacs23-bin-common 23.3+1-4 The GNU Emacs editor's shared, arc ii libasound2 1.0.24.1-3 shared library for ALSA applicatio ii libc6 2.13-7 Embedded GNU C Library: Shared lib ii libcairo2 1.10.2-6 The Cairo 2D vector graphics libra ii libdbus-1-3 1.4.12-4 simple interprocess messaging syst ii libfontconfig1 2.8.0-3 generic font configuration library ii libfreetype6 2.4.4-2 FreeType 2 font engine, shared lib ii libgdk-pixbuf2.0-0 2.23.5-1 GDK Pixbuf library ii libgif4 4.1.6-9 library for GIF images (library) ii libglib2.0-0 2.28.6-1 The GLib library of C routines ii libgpm2 1.20.4-3.4 General Purpose Mouse - shared lib ii libice6 2:1.0.7-2 X11 Inter-Client Exchange library ii libjpeg8 8c-2 Independent JPEG Group's JPEG runt ii libm17n-0 1.6.2-3 a multilingual text processing lib ii libncurses5 5.9-1 shared libraries for terminal hand ii libotf0 0.9.12-1 A Library for handling OpenType Fo ii libpng12-0 1.2.44-3 PNG library - runtime ii librsvg2-2 2.34.0-1 SAX-based renderer library for SVG ii libsm6 2:1.2.0-2 X11 Session Management library ii libtiff4 3.9.5-1 Tag Image File Format (TIFF) libra ii libtinfo5 5.9-4 shared low-level terminfo library ii libx11-6 2:1.4.4-2 X11 client-side library ii libxext6 2:1.3.0-3 X11 miscellaneous extension librar ii libxft2 2.2.0-3 FreeType-based font drawing librar ii libxmu6 2:1.1.0-2 X11 miscellaneous utility library ii libxpm4 1:3.5.9-1 X11 pixmap library ii libxrender1 1:0.9.6-2 X Rendering Extension client libra ii libxt6 1:1.1.1-2 X11 toolkit intrinsics library ii xaw3dg 1.5+E-18 Xaw3d widget set ii zlib1g 1:1.2.3.4.dfsg-3 compression library - runtime emacs23-lucid recommends no packages. Versions of packages emacs23-lucid suggests: ii emacs23-common-non-dfsg 23.3+1-1 GNU Emacs shared, architecture ind -- no debconf information -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
