GNOME Bugzilla – Bug 330833
Random (more or less) crash of every GTK+ application when AllChars is running
Last modified: 2008-08-19 22:02:08 UTC
Steps to reproduce: 1. Install "AllChars" ( http://allchars.zwolnet.com/ ) (must be under win32) 2. Be sure AllChars is Enabled 3. Launch X-Chat (other application crash, but I have a reproductible scenario with xchat) 4. Connect to a channel 5. Type anything (It's important to write, otherwise the crash doesn't occur) 6. Open the Settings window 7. XChat crash Stack trace: Other information: Almost all GTK+ I tested crash. It's always when a window should be opened. I never see a GTK+ Application crashed when the main window is opening. After a long search, I found the program AllChars is source of the problem. When in not "Enabled" (combo in AllChars configuration) there is no problem. Every binaries make applications crash (GTK+ 2.4 2.6 2.8, from serveral sources)
without even knowing what "AllChars" does, and without a stacktrace, it is impossible to do anything about this.
Allchars apparently is a 3rd-party keyboard input extension thingie. However, GTK+ works mostly fine with the official Microsoft keyboard layouts and IMEs. It's possible to switch between keyboard layouts at run-time and a running GTK+ application copes just fine with that. GTK+ also has its own way to input arbitrary Unicode code points (shift+control+hex digits). I don't really see any huge need for bending over backwards to support something nonstandard like AllChars. Glancing through the website, AllChars doesn't even seem to be Unicode oriented, the website talks only about codepage crap. AllChars also seems more or less dead. The last update is from 2001, and the author seems to be looking for somebody to dump it on... "So if you're interested in helping to make AllChars Open Source, please contact me. Please do not ask me for the source code." Huh? He wants to make it Open Source, but he doesn't want people to ask for the source code? Anyway, sure, if it requires only some trivial change, I am not against fixing GTK+ so that GTK+ apps don't crash with AllChars. But I certainly am not going to install it on my main development machine. I could try it quickly in a vmware virtual machine some day, and if the problem GTK+ has with AllChars is trivial to find and easy to fix I'll do it. If not, then somebody who is more interested in AllChars will have to debug the problem and send in a patch.
My main goal in reporting this bug was to help people having the same problem to solve it. Mainly because there is no clue at all that this problem is caused by AllChars. Anyway, AllChars doesn't work with GTK+ applications (it doesn't send keys, or more probably GTK+ applications doesn't receive the keys) but it doesn't crash either. It crash when opening some windows. So I don't feel like there IS work to do, only it SHOULD appear here to help people having the same problem to know that they should "Disable" AllChars.
I think that this is a dup of bug #316645 (Borland compiler issues).
I'll copy an informatice comment from bug #316645 here: * A few users have installed tools like virtual desktop managers, special graphics drivers or accessibility enhancements. These tools are indirectly loaded in GTK+ programs via keyboard hooks, calls from other DLLs, video codecs and other mechanisms. Some of these tools incorrectly modify the CPU flags and cause the floating point exceptions to become fatal errors (this is usually caused by tools compiled with Borland C/C++ or Delphi, using cbt.dll). If this AllChars problem really is caused by the same mechanism, there is nothing GTK+ can do. No further information has been provided either. Resolving as INCOMPLETE.