I've cloned an older bug because I'm effectively seeing the same problem, albeit with a newer version of ibus and with PhpStorm instead of Freemind. I think the Java app itself is irrelevant, it's the fact that it's a Java app that's pertinent. The symptoms are as described below, to whit: after running the app for a while (some hours) it refuses to respond to the keyboard any longer. Using the mouse still works. Restarting ibus-daemon causes PhpStorm to crash (it used to be that restarting the daemon would fix the problem for a while, but no longer). Restarting PhpStorm does resolve the problem for a time. +++ This bug was initially created as a clone of Bug #800736 +++ Description of problem: Please help with directions (package, or upstream bug tracker): I have first reported a bug about the Freemind package, in 2011, after losing keyboard input when using Japanese see: http://sourceforge.net/tracker/?func=detail&aid=3178894&group_id=7118&atid=107118 I have a limited understanding of interaction between the different software, but reading a similar issue ibus+java applications, see: https://bugs.launchpad.net/ubuntu/+source/ibus/+bug/481656 and http://code.google.com/p/ibus/issues/detail?can=2&q=&colspec=ID%20Component%20Type%20Status%20Priority%20Stars%20Milestone%20Owner%20Summary&groupby=&sort=&id=419 (closed) It seems that ibus, when used with Java applications, causes the lose of keyboard input. Version-Release number of selected component (if applicable): ibus 1.4.1 OpenJDK freemind 0.9 (Java application) Fedora 15 How reproducible: always Steps to Reproduce: 1. Open freemind (ibus working) 2. either input English (my default language) either Japanese 3. Actual results: after some time, any key press is ineffective in the Java application. The workaround is to turn off ibus. Expected results: Input Japanese (using ibus) in Freemind. Additional info: --- Additional comment from fujiwara on 2012-03-07 01:33:33 EST --- Which shortcut keys do you try to use? --- Additional comment from nomnex on 2012-03-07 04:48:37 EST --- no shortcut. Ibus is running, I start Freemind. I can input English, or Japanese, but after a (short) time, any key press stop working in the Java application (I can only mouse click on the menus.) It only affects the Freemind GUI, outside of it, I can type. To re-gain keyboard input in Freemind, I must stop ibus. Then I can type again in Freemind. If I restart ibus, I can't input Japanese in the Freemind window (I can's select Japanese input[MOZEC or ANTHY] as long as Freemind window is in focus. If I click on a another window, I can select Japanese input as usual). If I want to input Japanese again in Freemind, I must first terminate Freemind, and re-open it. --- Additional comment from nomnex on 2012-03-12 01:48:05 EDT --- It there a way I can help debugging this on my end? I have no message when I launch Freemind from the terminal, and when the bug occurs. After a few minutes of usage, I can not type anything in Freemind. The keyboard is not responsive. The only workaround is to quit ibus. can you reproduce the issue, or am I the only one affected by this problem? java version "1.6.0_22" OpenJDK Runtime Environment (IcedTea6 1.10.6) (fedora-63.1.10.6.fc15-i386) OpenJDK Client VM (build 20.0-b11, mixed mode) Thank you. --- Additional comment from fujiwara on 2012-03-12 02:19:14 EDT --- I don't think ibus does not work with Java applications. I guess a Freemind bug or setting failures something. I'm a bit busy for F17. It would be nice if you could confirmed the behavior with jedit. --- Additional comment from nomnex on 2012-03-13 10:47:03 EDT --- (In reply to comment #4) > I guess a Freemind bug or setting failures something. I'm a bit busy for F17. Of course, I understand. > It would be nice if you could confirmed the behavior with jedit. I installed jedit jar (all platform) in my user directory for a test run. It may not be the proper installation, because Java path was not defined. I did not find a rpm jedit. Running $ jedit, I can input Japanese fine. This is the exact symptom I experience when I use Freemind & ibus: --start-- https://bugs.launchpad.net/ubuntu/+source/ibus/+bug/481656 I use ThinkingRock, a Java application, and after some time the keyboard input stops working for this application, meaning I can still use my mouse to manipulate the program, but I cannot type anything. When closing the iBus Daemon the input works again after some seconds. Also restarting the Java application helps to postpone the problem until it occurs again some minutes later. I'm using Ubuntu 9.10 with version 1.2.0.20090927-2ubuntu2 of iBus and version 2.2.1 of ThinkingRock. My Java version is 6-15-1. Please notice: I do NOT want to input Chinese or Japanese or anything like it. I just want to normally use my keyboard. I also have NO input method selected, I have the input methods turned OFF. I have yet to test this behavior with other Java applications (maybe it's a bug in ThinkingRock?), so I'd be happy if somebody can confirm this bug for other Java applications. Because the solution is to quit the iBus Daemon, I suspect iBus to be the problem. --end-- a ibus developer commented on the launchpad bug: Peng Huang (shawn-p-huang) #comment 3 --- Additional comment from nomnex on 2012-03-13 19:46:53 EDT --- I think I found the problem: - This notebook suffers a LXDE panel bug (known bug). - My other notebook with integrated GPU Intel and similar F-15 LXDE is not affected by the LXDE panel bug. I tried Freemind + ibus and it worked fine. From this starting point, I changed ibus preferences: Show icon on system tree (Cleared) It seems to work! I don't lose input in Freemind after a few minutes. On question: I lost the ability to turn ibus input on-off with a mouse click (the input, not the daemon). What is the command line to turn ibus input on-off? Thank you again. --- Additional comment from nomnex on 2012-03-14 02:27:34 EDT --- It does not work... after a few hours (vs. a few minutes, before) the bug is here again. The keyboard cannot input anything in the Freemind window, unless I kill ibus-daemon. Gosh. --- Additional comment from nomnex on 2012-03-26 05:36:50 EDT --- The cause of the input problem was: LXPANEL. Changing panel (XFCE) on my system solved the issue. I can input Japanese in Freemind. See for information: https://bugzilla.redhat.com/show_bug.cgi?id=803098 Thank you.
Thank you Richard. I am still affected by the same bug, no matter the Fedora version or i-bus version, every time I use Freemind. Reading the longstanding launchpad bug report ‘i-bug + Java applications’ about the exact same issue, this not a single case. It was difficult to report the bug and to understand Fujiwara explanations at the time, because I other problem on this system, and I lack technical expertise.
(In reply to Richard J. Turner from comment #0) > I've cloned an older bug because I'm effectively seeing the same problem, > albeit with a newer version of ibus and with PhpStorm instead of Freemind. I > think the Java app itself is irrelevant, it's the fact that it's a Java app > that's pertinent. > > The symptoms are as described below, to whit: after running the app for a > while (some hours) it refuses to respond to the keyboard any longer. Using > the mouse still works. Restarting ibus-daemon causes PhpStorm to crash (it > used to be that restarting the daemon would fix the problem for a while, but > no longer). Restarting PhpStorm does resolve the problem for a time. > I cannot reproduce the keyboard response problem. If you can see the same problem, please provide the sample program code besides PhpStorm. The crash is caused by Java app and closing the bug: Probably I think that application needs to call XSetIMValues($XIM, XNDestroyCallback, callback_function) so that XCreateIC() can be called again after ibus-daemon restart. # SIGSEGV (0xb) at pc=0x0000003d6c4501ca, pid=25391, tid=140074881537792 # # JRE version: OpenJDK Runtime Environment (8.0_11-b12) (build 1.8.0_11-b12) # Java VM: OpenJDK 64-Bit Server VM (25.11-b02 mixed mode linux-amd64 compressed oops) # Problematic frame: # C [libX11.so.6+0x501ca] XSetICValues+0xfa # Stack: [0x00007f65b97e5000,0x00007f65b98e6000], sp=0x00007f65b98e2740, free space=1013k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C [libX11.so.6+0x501ca] XSetICValues+0xfa Java frames: (J=compiled Java code, j=interpreted, Vv=VM code) j sun.awt.X11.XInputMethod.setXICFocusNative(JZZ)V+0 j sun.awt.X11.XInputMethod.setXICFocus(Ljava/awt/peer/ComponentPeer;ZZ)V+25 j sun.awt.X11InputMethod.activate()V+162 j sun.awt.im.InputContext.activateInputMethod(Z)V+169 j sun.awt.im.InputContext.focusGained(Ljava/awt/Component;)V+137 J 7512 C1 sun.awt.im.InputContext.dispatchEvent(Ljava/awt/AWTEvent;)V (173 bytes) @ 0x00007f65c35c253b [0x00007f65c35c0da0+0x179b] J 7150 C1 sun.awt.im.InputMethodContext.dispatchEvent(Ljava/awt/AWTEvent;)V (62 bytes) @ 0x00007f65c34457e5 [0x00007f65c3444ee0+0x905] J 8017 C1 java.awt.Component.dispatchEventImpl(Ljava/awt/AWTEvent;)V (883 bytes) @ 0x00007f65c37ded34 [0x00007f65c37dbf40+0x2df4] J 8129 C2 java.awt.Container.dispatchEventImpl(Ljava/awt/AWTEvent;)V (129 bytes) @ 0x00007f65c382e854 [0x00007f65c382e800+0x54] J 3885 C1 java.awt.Component.dispatchEvent(Ljava/awt/AWTEvent;)V (6 bytes) @ 0x00007f65c2b6bd37 [0x00007f65c2b6bc40+0xf7] j java.awt.KeyboardFocusManager.redispatchEvent(Ljava/awt/Component;Ljava/awt/AWTEvent;)V+7 j java.awt.DefaultKeyboardFocusManager.typeAheadAssertions(Ljava/awt/Component;Ljava/awt/AWTEvent;)Z+335 J 7418 C2 java.awt.DefaultKeyboardFocusManager.dispatchEvent(Ljava/awt/AWTEvent;)Z (1589 bytes) @ 0x00007f65c358c9f8 [0x00007f65c358b120+0x18d8] J 8017 C1 java.awt.Component.dispatchEventImpl(Ljava/awt/AWTEvent;)V (883 bytes) @ 0x00007f65c37dd2c0 [0x00007f65c37dbf40+0x1380] J 8129 C2 java.awt.Container.dispatchEventImpl(Ljava/awt/AWTEvent;)V (129 bytes) @ 0x00007f65c382e854 [0x00007f65c382e800+0x54] J 8178 C2 java.awt.EventQueue$3.run()Ljava/lang/Object; (5 bytes) @ 0x00007f65c2807614 [0x00007f65c28072a0+0x374] v ~StubRoutines::call_stub J 4580 java.security.AccessController.doPrivileged(Ljava/security/PrivilegedAction;Ljava/security/AccessControlContext;)Ljava/lang/Object; (0 bytes) @ 0x00007f65c23721a3 [0x00007f65c2372140+0x63] J 4880 C1 java.security.ProtectionDomain$1.doIntersectionPrivilege(Ljava/security/PrivilegedAction;Ljava/security/AccessControlContext;Ljava/security/AccessControlContext;)Ljava/lang/Object; (32 bytes) @ 0x00007f65c29709c4 [0x00007f65c29706e0+0x2e4] J 6812 C1 java.awt.EventQueue$4.run()Ljava/lang/Object; (5 bytes) @ 0x00007f65c331b929 [0x00007f65c331b560+0x3c9] v ~StubRoutines::call_stub J 4580 java.security.AccessController.doPrivileged(Ljava/security/PrivilegedAction;Ljava/security/AccessControlContext;)Ljava/lang/Object; (0 bytes) @ 0x00007f65c23721a3 [0x00007f65c2372140+0x63] J 8188 C2 com.intellij.ide.IdeEventQueue.e(Ljava/awt/AWTEvent;)V (52 bytes) @ 0x00007f65c2e0bc04 [0x00007f65c2e0b8e0+0x324] J 8152 C2 com.intellij.ide.IdeEventQueue._dispatchEvent(Ljava/awt/AWTEvent;Z)V (886 bytes) @ 0x00007f65c38bf8a8 [0x00007f65c38bba20+0x3e88] J 8177 C2 com.intellij.ide.IdeEventQueue.dispatchEvent(Ljava/awt/AWTEvent;)V (311 bytes) @ 0x00007f65c2809518 [0x00007f65c28093e0+0x138] J 8586 C2 java.awt.EventDispatchThread.pumpOneEventForFilters(I)V (295 bytes) @ 0x00007f65c3923228 [0x00007f65c3922fa0+0x288] j java.awt.EventDispatchThread.pumpEventsForFilter(ILjava/awt/Conditional;Ljava/awt/EventFilter;)V+35 j java.awt.EventDispatchThread.pumpEventsForHierarchy(ILjava/awt/Conditional;Ljava/awt/Component;)V+11 j java.awt.EventDispatchThread.pumpEvents(ILjava/awt/Conditional;)V+4 j java.awt.EventDispatchThread.pumpEvents(Ljava/awt/Conditional;)V+3 j java.awt.EventDispatchThread.run()V+9 v ~StubRoutines::call_stub
(In reply to fujiwara from comment #2) > I cannot reproduce the keyboard response problem. If you can see the same > problem, please provide the sample program code besides PhpStorm. I don't understand what you mean by "please provide the sample program code besides PhpStorm". I frequently see this problem, it interrupts my work. Do you mean for me to build a sample Java app that exhibits the same behaviour? That I can't do; I'm not a Java developer. > The crash is caused by Java app and closing the bug: Surely if ibus-daemon wasn't crashing in the first place there would be no need for the Java app to deal with that crash gracefully? Since it appears to affect two different Java applications it seems unlikely to me that those applications are the cause of the problem, but I'll grant that I haven't the skill to investigate myself. I'm keen to see this bug fixed rather than brushed under the carpet though, and to that end I'll happily provide whatever information I can to help.
Here's the relevant bug report for IntelliJ IDEA (upon which PhpStorm is based): https://youtrack.jetbrains.com/issue/IDEA-78860
(In reply to Richard J. Turner from comment #3) > (In reply to fujiwara from comment #2) > > I cannot reproduce the keyboard response problem. If you can see the same > > problem, please provide the sample program code besides PhpStorm. > > I don't understand what you mean by "please provide the sample program code > besides PhpStorm". I frequently see this problem, it interrupts my work. Do > you mean for me to build a sample Java app that exhibits the same behaviour? > That I can't do; I'm not a Java developer. If you can't, please find another Java application besides PhpStorm since I cannot reproduce your problem. > > The crash is caused by Java app and closing the bug: > > Surely if ibus-daemon wasn't crashing in the first place there would be no > need for the Java app to deal with that crash gracefully? No, ibus-daemon does not crash but the Java app crashed. It would be a bug in PhpStorm or linked libraries. > Since it appears to affect two different Java applications it seems unlikely Two? Are yourself reproduce the same issue with another application? Try Jedit.
(In reply to fujiwara from comment #5) > > I don't understand what you mean by "please provide the sample program code > > besides PhpStorm". I frequently see this problem, it interrupts my work. Do > > you mean for me to build a sample Java app that exhibits the same behaviour? > > That I can't do; I'm not a Java developer. > > If you can't, please find another Java application besides PhpStorm since I > cannot reproduce your problem. Someone else wrote a program that also exhibits the problem here: https://bugs.openjdk.java.net/browse/JDK-6506617 > > Since it appears to affect two different Java applications it seems unlikely > > Two? Are yourself reproduce the same issue with another application? > Try Jedit. Two because nomnex says he is "still affected by the same bug ... every time [he uses] Freemind". Although the YouTrack bug I referenced mentions that NetBeans also exhibits the same behaviour, so that's three apps plus the sample on the OpenJDK bug report. Unlike nomnex, who says that it takes minutes for the problem to occur, I probably see this three or four times a day working with PhpStorm 9am-5pm; perhaps reproducing it is just a matter of time (I appreciate that you can't spend all day tinkering with PhpStorm trying to reproduce this though!). As someone mentioned on the YouTrack bug I referenced, it does seem to manifest itself when app switching, although I think switching using the mouse is just as likely to trigger it as switching with the keyboard. As I said, I'm no Java dev; is there anything I can set in the JVM to collect debugging info that might be useful for you?
(In reply to Richard J. Turner from comment #6) > Someone else wrote a program that also exhibits the problem here: > https://bugs.openjdk.java.net/browse/JDK-6506617 I cannot reproduce your problem with KeyLock.java. Did you try that program? > Two because nomnex says he is "still affected by the same bug ... every time > [he uses] Freemind". Although the YouTrack bug I referenced mentions that > NetBeans also exhibits the same behaviour, so that's three apps plus the > sample on the OpenJDK bug report. Probably I don't think that problem and your problem is same. And did yourself reproduce your problem with freemind? > Unlike nomnex, who says that it takes minutes for the problem to occur, I > probably see this three or four times a day working with PhpStorm 9am-5pm; > perhaps reproducing it is just a matter of time (I appreciate that you can't > spend all day tinkering with PhpStorm trying to reproduce this though!). I will try phpstorm today again but probably I think I won't reproduce your problem. > As I said, I'm no Java dev; is there anything I can set in the JVM to > collect debugging info that might be useful for you? Please find which key sequences causes your problem and it might be good to attach your project file. I just tried a new project. I guess the most critical problem is the crash and it's a java app bug as I explained in comment #2. If you run phpstorm from a terminal and run the application from phpstorm, the SEGV message will be shown on the terminal and you could report it in phpstorm.
Created attachment 942609 [details] reproducer code This happens when giving an invalid XIC, which most likely to happen after restarting an input method. To avoid this crash, Java has to use XRegisterIMInstantiateCallback/XUnregisterIMInstantiateCallback and initialize the XIM and XIC instance properly.
This message is a reminder that Fedora 21 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 21. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '21'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 21 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Is this bug still exist in F23? Is not please close else move to F23. We don't want to loose any valuable bug :)
Happily I'd forgotten about this bug; it doesn't exist in F22 or F23.