Bugzilla – Bug 134531
emacs gets signal 11 for tcsh uesrs, lack of system profile support?!
Last modified: 2007-06-04 13:06:50 UTC
Run emacs in X window, type 2 characters and it core dumps. If I run it w/ -nw, works. If I run it in X but after su to root, it works. If I run it as myself, in X, but after su to root and su back to me, it works. Info: # uname -a Linux voyager 2.6.13-15-default #1 Tue Sep 13 14:56:15 UTC 2005 i686 i686 i386 GNU/Linux # cat /etc/SuSE-release SUSE LINUX 10.0 (i586) VERSION = 10.0 # gdb `which emacs` core #0 0xffffe410 in __kernel_vsyscall () (gdb) bt #0 0xffffe410 in __kernel_vsyscall () #1 0x4039f886 in kill () from /lib/tls/libc.so.6 #2 0x080e3a36 in abort () #3 <signal handler called> #4 _XimOffKeysCheck (ic=0x84fd628, ev=0xbff49d78) at imDefFlt.c:114 #5 0x4061f414 in _XimFilterKeypress (d=0x84b5858, w=58720468, ev=0xbff49d78, client_data=0x84fd628 "") at imDefFlt.c:181 #6 0x40288f0a in XFilterEvent () from /usr/X11R6/lib/libX11.so.6 #7 0x080c8082 in ?? () ... - Jimmy
BTW my shell is /bin/tcsh. I created a test account w/ /bin/bash, and that account worked OK. There must be some profile stuff that's not done for tcsh / csh login shells, e.g. root's 'set' output and my 'set' output are different: - LANG is not defined in my login shell. - arr is not defined in ny login shell. - Jimmy
I have installed Simplified Chinese / Traditional Chinese / Korean / Japanese fonts on the SuSE 10 system, just like my SuSE 9.3 system. The default is English/US. The lack of LANG in my tcsh environment makes sense in terms of the behavior (X tried to look up a multi-byte character after two key strokes). What I haven't tracked down yet is what is missing in the profile / skel for tcsh users in SuSE 10.0. 9.3 worked fine w/ the almost identical X server and my user account configurations. Please let me know what additional info you need. I'd appreciate very much if a workaround / patch can be available soon. - Jimmy
From this link below: http://www.suse.de/~mfabian/suse-cjk/locales-sysconfig.html I tried SuSEconfig --module profiles manually, hoping to populate the empty /etc/SuSEconfig/ directory on my 10.0 installation. SuSEconfig complains that there's no such module :( Looking at /sbin/SuSEconfig, the module should be /sbin/conf.d/SuSEconfig.<module>. Although /sbin/SuSEconfig comes from aaa_base, aaa_base doesn't provide most of the existing /sbin/conf.d/SuSEconfig.<module> files. I am stuck. Providing a ~/.login setenv / set LANG to en_US.UTF-8 doesn't work either (I logged out of X session / gdm and logged back in to test the changes). - Jimmy
Hmm ... I'm emacs and tcsh user and here it does not crash. Please do NOT unset LANG nor any other variable but report if it works _with_ a normal locale environment.
I think I found the smoking gun, SCIM: - Created another tcsh account, restarted gdm session as that user, and emacs works. - One major difference is that I customized the SCIM trigger key bindings to quell the annoying 'shift-space' induced SCIM menu (actually I went ahead and deleted all trigger key bindings). The intention was to 'disable' SCIM altogether. But in the new tcsh user environment, it was the default SCIM configuration. - Compared to my 9.3 setup, I think in 9.3 I just unchecked the secondary languages that I selected during install, but in 10.0 I did it by deleting the key bindings in SCIM. So I went ahead just then and unchecked the secondary languages through YAST. After that (and restarting gdm session), emacs starts to work in my own account environment. I don't know if the SCIM keybinding deletion is my user error or not (I've never used SCIM, and the secondary languages selection during install was just a lazy approach to get all the Chinese / Japanese / Korean fonts installed by the installer). If you want to dig deeper into this issue, I think you can reproduce the problem as follows: - install (or w/ YAST 'Languages' configuration), select secondary languages involving Chinese / Japanese / Korean - restart X session - type 'shift-space' and you should see the SCIM language selection menu - get into SCIM configuration menus, and delete all 'trigger' key bindings. - restart X session - emacs starts to core dump on two key presses. But, given that I've found a way to avoid the core dump, I would not mind if you just dispose this report. Thanks. - Jimmy
Created attachment 59322 [details] List of xorg-x11 RPMs used to produce stack trace.
Created attachment 59323 [details] gdb bt output
Created attachment 59324 [details] Core file.
Created attachment 59325 [details] /var/log/Xorg.0.log
Oops, I attached to the wrong defect. Please ignore. - Jimmy
Mike? SCIM is some of your favorites.
We cannot reproduce a crash but when trying to use SCIM in Emacs, Emacs hangs sucking cpu time after inputting a few characters. Tested using scim-anthy. Input of あ works but input of 感じ hangs.
Reassign to Zhe Su <zsu@novell.com>. Zhe, do you have any idea what happens here?
Installing Mule-UCS solves the problem with the hanging when inputting Japanese kanji.
Question to the original bug reporter: Is the Mule-UCS installed on your system.
I'm not familiar with emacs, so don't know what's the matter it is. However, one of my colleague told me before, that it's a bug of emacs, and can be fixed by a piece of elisp code. I'll cc this bug to him.
Yes, mule-ucs is something must needed for emacs 21.3 to work in a CJK UTF environment (not perfect though). But without mule-ucs, you still can use C-g to prevent from hanging. I can't reproduce the Oops metioned in the original report.
No I didn't have mule-ucs on my system. Please read my posting on Nov. 21 2005 and see if you have followed the scenario I had in reproducing this. I'm not too sure, but I vaguely remember, when the core dump happened, Ctrl-g counted as two key presses (and therefore core dumps :/) ... and I can see you didn't have the same problem because of that :) - Jimmy
BTW let me clarify the role of CJK-UTF setup on my system if it helps you to reproduce (or just to assess the priority of this defect): - I can read Chinese but not very good at using input methods. Therefore my primary intention of installing CJK was the fonts, not the input methods. - When I installed SuSE 10.0, I selected secondary languages Chinese, Korean, Japanese, with the expectation that the related fonts would be installed (instead of having to select the fonts in the software package menu). I think this can also be done through YaST post-installation. - My primary / default locale / LANG remains en-US. - As a developer my primary editor of choice is emacs. The presence of SCIM in my X session, particularly the trigger key binding (e.g. shift-space), coupled with my particular typing habit / skill, makes SCIM a pretty annoying presence because of the more than occasional pop-up of the language selection menu during normal typing. - While I should have just uninstalled SCIM (through unchecking the secondary languages in YaST), I somehow opted to open the SCIM configuration and zapped all key bindings that may activate SCIM, so that SCIM will never get in the way. - And this led to the emacs-x11 core dump on two key presses. Therefore, this bug is not related to _normal_ use of SCIM. If you want to test the input methods of SCIM relatd to emacs X11, you may not reproduce it. If your default / current locale is not en-US or something that doesn't involve multi-byte characters, you may not reproduce it. I don't know if it's really a emacs-x11 issue. From what I can tell, if uninstalling SCIM makes a difference, then there must be something wrong with SCIM ... after all my default locale is en-US and normal English text editting should not behave differently with or without SCIM in the middle. - Jimmy
I found that if emacs is running in non-utf8 locale, like zh_CN.GB2312 or ja_JP, then it won't be hang, even if the language is switched back to UTF-8 inside emacs. So I think there is something wrong in emacs's xim encoding handling code.
According to our local emacs guru, this issue could be solved by upgrading emacs to the latest cvs version. So reassign this report to Werner to see whether it's possible to upgrade emacs or backport the fix.
The difference between CVS and current stable version is to large. The basis of the CVS version is wide character support including UTF-8 whereas the current version uses lisp support for that.
With the last update to emacs 22.0.99 this problem should be gone.
fixed with update to emacs 22.0.99, hopefully