Bug 280031 - scim-bridge may crash X when switching input methods
scim-bridge may crash X when switching input methods
Status: CLOSED WONTFIX
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: xorg-x11-server (Show other bugs)
5.0
i686 Linux
high Severity high
: ---
: ---
Assigned To: Adam Jackson
desktop-bugs@redhat.com
: Triaged
Depends On:
Blocks: 726826
  Show dependency treegraph
 
Reported: 2007-09-06 01:28 EDT by Yan Li
Modified: 2011-08-12 19:45 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2011-08-12 19:45:03 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Xorg.0.log right after crash (40.56 KB, text/plain)
2007-10-11 05:13 EDT, Yan Li
no flags Details
Xorg.0.log.old right after crash (41.19 KB, text/plain)
2007-10-11 05:14 EDT, Yan Li
no flags Details
last lines of '/var/log/messages' right after crash (3.28 KB, text/plain)
2007-10-11 05:16 EDT, Yan Li
no flags Details
xsession-errors (6.78 KB, text/plain)
2007-10-14 07:00 EDT, Yan Li
no flags Details
message after X lock up on Nov 20, 2007 (1.75 KB, text/plain)
2007-11-25 08:51 EST, Yan Li
no flags Details
Xorg.0.log after X lock up on Nov 20, 2007 (101.04 KB, text/plain)
2007-11-25 08:51 EST, Yan Li
no flags Details
Xorg.0.log.old after X lock up on Nov 20, 2007 (101.06 KB, text/plain)
2007-11-25 08:52 EST, Yan Li
no flags Details
~/.xsession-errors after X lock up on Nov 25, 2007 (12.83 KB, text/plain)
2007-11-25 08:54 EST, Yan Li
no flags Details

  None (edit)
Description Yan Li 2007-09-06 01:28:09 EDT
Description of problem:
When switching input methods between scim and English Keyboard by using
hot-keys, X server may crash. This happened once per 2~3 days. And these info
could be found in /var/log/message:
====== BEGIN ======
Sep  5 18:27:38 kgardenia scim-bridge: FIXME: A critical error occurred on the
socket!
Sep  5 18:27:38 kgardenia scim-bridge: Panel client has not yet been prepared
Sep  5 18:27:38 kgardenia last message repeated 2 times
Sep  5 18:27:38 kgardenia scim-bridge: The lockfile is destroied
Sep  5 18:27:38 kgardenia scim-bridge: Cleanup, done. Exitting...
Sep  5 18:27:40 kgardenia gconfd (tina-3374): Received signal 15, shutting down
cleanly
====== END ======

Version-Release number of selected component (if applicable):
# rpm -qa | grep scim
scim-hangul-0.2.2-7.fc6
scim-tables-0.5.6-7
scim-bridge-gtk-0.4.5-7.el5
scim-tables-chinese-0.5.6-7
scim-libs-1.4.4-39.el5
scim-pinyin-0.5.91-15.el5
scim-chinese-standard-0.0.2-1.el5
scim-chewing-0.3.1-10.el5
scim-anthy-1.2.0-5.el5
scim-bridge-0.4.5-7.el5
scim-qtimm-0.9.4-5
scim-1.4.4-39.el5


How reproducible:
I could meet crashes every 2~3 days, when switching input method (between scim
and English Keyboard) by using my hot-key "Ctrl-Alt-Q."

Steps to Reproduce:
1. Switch input method (between scim and English Keyboard) by using my hot-key
"Ctrl-Alt-Q."
2. Try step 1 many times...

Actual results:
Most time this switch is OK, but every 2~3 days I met a crash and could find
logs as shown above.

Expected results:
Switching is OK.
Comment 1 Jens Petersen 2007-10-08 21:37:19 EDT
So the problem is the log messages or is your X server actually going down?
Comment 2 Yan Li 2007-10-08 21:48:39 EDT
X server actually went down when the crash occured, and after the crash I could
find the log as shown above in /var/log/message.

I used hot-key switch heavily, and could meet the whole X crash due to this
every 2~3 days.

Fedora Core 6 doesn't have this problem, with same configuration.
Comment 3 Jens Petersen 2007-10-08 21:54:13 EDT
Thanks for the clarification.
Comment 4 Peng Huang 2007-10-08 22:54:47 EDT
What is actual results? Your screen goto text mode, your computer restart a new
X server or the X server did not response?

If X server crash again, please send /var/log/Xorg.0.log and
/var/log/Xorg.0.log.old to me.

Comment 5 Yan Li 2007-10-09 03:42:41 EDT
The screen went to text mode, showed the text login prompt, and if I pressed
Alt+f7, there was a blank screen.

I remember I see nothing special in Xorg.0.log.  I'll send you the logs on next
crash.
Comment 6 Yan Li 2007-10-11 05:13:39 EDT
Created attachment 224151 [details]
Xorg.0.log right after crash

X crashed again just now when I was toggling the SCIM panel with my own
shortcut key 'Ctrl-Alt-Q'.  I'll attach 'Xorg.0.log', 'Xorg.0.log.old' and
excerpt of '/var/log/messages'.
Comment 7 Yan Li 2007-10-11 05:14:23 EDT
Created attachment 224161 [details]
Xorg.0.log.old right after crash
Comment 8 Yan Li 2007-10-11 05:16:11 EDT
Created attachment 224181 [details]
last lines of '/var/log/messages' right after crash
Comment 9 Yan Li 2007-10-11 05:17:56 EDT
Not like before, after this crash, the X restart itself automatically and I was
facing the normal GUI login screen.
Comment 10 Peng Huang 2007-10-11 06:08:23 EDT
I did not find anything valuable info in the log files. Although it is caused by
SCIM's operations, but I think it should be a X server's BUG.

Comment 11 Jens Petersen 2007-10-12 05:10:00 EDT
However you're using fglrx so probably the X team will not look at this.

Is there anything in ~/.xsession-errors ?
Comment 12 Jens Petersen 2007-10-12 05:10:52 EDT
And if you don't use your hotkey but just the default Ctrl+Space say?
Comment 13 Yan Li 2007-10-14 07:00:14 EDT
Created attachment 226601 [details]
xsession-errors

This is the current ".xsession-errors" file (about 2 days after the crash). 
I'm not sure whether there's any thing useful in it. 

As to the "fglrx" driver, I'll disable it.  And I'll change the shortcut key
back to "Ctrl-Space" to try.  I'll post if the crash happened again.
Comment 14 RHEL Product and Program Management 2007-10-15 23:42:10 EDT
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release.  Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products.  This request is not yet committed for inclusion in an Update
release.
Comment 15 Adam Jackson 2007-11-09 13:30:47 EST
Devel ack, assuming we can reproduce this.
Comment 17 Yan Li 2007-11-25 08:48:40 EST
My laptop have been worked OK for me since last error report for some weeks, but
this week, it locked up for several times. X didn't crash, but just locked up.
And mouse point can NOT move. No fglrx now, using default hot-key. For recent
lock-up, they didn't occur during switching input methods, but often when I was
just moving my mouse pointer with the ThinkPad's red point.
Comment 18 Yan Li 2007-11-25 08:51:20 EST
Created attachment 268171 [details]
message after X lock up on Nov 20, 2007

From the message, I still suspect that SCIM was the cause to this lock-up.
Comment 19 Yan Li 2007-11-25 08:51:45 EST
Created attachment 268181 [details]
Xorg.0.log after X lock up on Nov 20, 2007
Comment 20 Yan Li 2007-11-25 08:52:12 EST
Created attachment 268191 [details]
Xorg.0.log.old after X lock up on Nov 20, 2007
Comment 21 Yan Li 2007-11-25 08:54:34 EST
Created attachment 268201 [details]
~/.xsession-errors after X lock up on Nov 25, 2007
Comment 22 Adam Jackson 2008-01-17 13:39:43 EST
I loaded every possible SCIM input method, set my input method switch key to F8,
set a weight on it, and walked away overnight.  No lockup.

Moving to 5.3 radar.   If a more reliable way of reproducing this comes up feel
free to move back to 5.2.
Comment 23 Yan Li 2008-01-17 20:52:10 EST
Ajax, thanks for your testing. Your testing method is very good. Here's my
thought, hope to be helpful.

From the normal user's perspective, there may be other things caused the lock
up, such as switching the input method with several Qt and GTK programs running
together, or there maybe something internal went wrong in one specific input
method (I have been using simplified Chinese) while you are 'using' it and lead
to the lock up later when you switch off the input method. Just guess.

From the programmer's perspective, I highly suspect the following warnings,
which appeared before the lock up, in /var/log/message (as in last attachment):
Oct 11 17:02:26 kgardenia scim-bridge: Failed to open the panel socket
Oct 11 17:02:26 kgardenia scim-bridge: FIXME: A critical error occurred on the
socket!
Oct 11 17:02:26 kgardenia scim-bridge: Panel client has not yet been prepared
Oct 11 17:02:26 kgardenia last message repeated 11 times
...
Oct 11 17:02:26 kgardenia scim-bridge: Panel client has not yet been prepared
Oct 11 17:02:26 kgardenia last message repeated 224 times
Oct 11 17:02:26 kgardenia scim-bridge: The lockfile is destroied
Oct 11 17:02:26 kgardenia scim-bridge: Cleanup, done. Exitting...

I guess there maybe something wrong within scim-bridge.

BTW: I haven't met lock up recently for about 1 month, after updated to 5.1.
I'll report back if I met more. Thanks!
Comment 24 Peng Huang 2008-01-17 21:53:58 EST
(In reply to comment #23)
> From the programmer's perspective, I highly suspect the following warnings,
> which appeared before the lock up, in /var/log/message (as in last attachment):
> Oct 11 17:02:26 kgardenia scim-bridge: Failed to open the panel socket
> Oct 11 17:02:26 kgardenia scim-bridge: FIXME: A critical error occurred on the
> socket!
> Oct 11 17:02:26 kgardenia scim-bridge: Panel client has not yet been prepared
> Oct 11 17:02:26 kgardenia last message repeated 11 times
> ...
> Oct 11 17:02:26 kgardenia scim-bridge: Panel client has not yet been prepared
> Oct 11 17:02:26 kgardenia last message repeated 224 times
> Oct 11 17:02:26 kgardenia scim-bridge: The lockfile is destroied
> Oct 11 17:02:26 kgardenia scim-bridge: Cleanup, done. Exitting...
> 
> I guess there maybe something wrong within scim-bridge.

scim-bridge is a deamon. It is not an X application. It will communicate with
Panel client that is an X application. So when Xserver is crashed, the Panel
client will be closed too. And then the scim-bridge will lost the connection
with Panel Client. I guess the log is for that.
Comment 30 RHEL Product and Program Management 2011-08-12 19:45:03 EDT
Development Management has reviewed and declined this request.  You may appeal
this decision by reopening this request.

Note You need to log in before you can comment on or make changes to this bug.