Bug 653806
Summary: | [abrt] ibus-1.3.7-11.fc14: XkbGetState: Process /usr/libexec/ibus-xkb was killed by signal 11 (SIGSEGV) | ||||||
---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Reinier Balt <lrbalt> | ||||
Component: | ibus | Assignee: | fujiwara <tfujiwar> | ||||
Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
Severity: | medium | Docs Contact: | |||||
Priority: | low | ||||||
Version: | 14 | CC: | i18n-bugs, shawn.p.huang, tfujiwar | ||||
Target Milestone: | --- | ||||||
Target Release: | --- | ||||||
Hardware: | i686 | ||||||
OS: | Unspecified | ||||||
Whiteboard: | abrt_hash:65ff1475df8026e03b940d1a6a6f175e7e3f7837 | ||||||
Fixed In Version: | ibus-1.3.7-14.fc14 | Doc Type: | Bug Fix | ||||
Doc Text: | Story Points: | --- | |||||
Clone Of: | Environment: | ||||||
Last Closed: | 2010-11-22 09:12:45 UTC | Type: | --- | ||||
Regression: | --- | Mount Type: | --- | ||||
Documentation: | --- | CRM: | |||||
Verified Versions: | Category: | --- | |||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
Cloudforms Team: | --- | Target Upstream Version: | |||||
Embargoed: | |||||||
Attachments: |
|
Description
Reinier Balt
2010-11-16 08:09:36 UTC
Created attachment 460769 [details]
File: backtrace
I know that issue but currently ibus-xkb is called by ibus panel only and it would need to open $DISPLAY. I'm not sure why you'd like to run ibus-xkb with command line without $DISPLAY. I did not run it myself. I logged in using nx. Perhaps the display was not ready while nx was starting? (In reply to comment #3) > I did not run it myself. I logged in using nx. Perhaps the display was not > ready while nx was starting? OK, I see. I don't try NoMachine. Probably ibus panel needs to retry to open the DISPLAY later from your reply. I tried NX but I don't see any errors. Installed rpms: NX Free Edition for Linux nxclient-3.4.0-7.x86_64.rpm nxnode-3.4.0-14.x86_64.rpm nxserver-3.4.0-14.x86_64.rpm NX server is Fedora14 NX client is Fedora13 server# /usr/NX/bin/nxserver --status NX> 900 Connecting to server... NX> 110 NX Server is running NX> 999 Bye. client% grep -i desktop $HOME/.nx/config/Fedora14.nxs <option key="Custom Unix Desktop" value="console" /> <option key="Desktop" value="gnome" /> <option key="Virtual desktop" value="false" /> When I run the session, GNOME is launched. /usr/NX/bin/nxclient --session "$HOME/.nx/config/Fedora14.nxs" It seems the Free edition launch the en_US.UTF-8 and ibus is not executed by default. So I guess you enabled ibus after you run im-chooser. If ibus is not running, ibus-xkb is also not running and this bug won't be happened. I could run ibus without any problems. % ps -ef | grep ibus % ibus-daemon --xim & % env GTK_IM_MODULE=ibus gedit I googled about NX and I guess you might use the old NX: http://www.kanotix.com/files/fix/sidux/45xsession.orig ibus could open DISPLAY in my session with NX. % xauth list localhost.localdomain:1002 MIT-MAGIC-COOKIE-1 0501ad.... server/unix:1002 MIT-MAGIC-COOKIE-1 0501ad.... server:1002 MIT-MAGIC-COOKIE-1 0501ad.... server/unix:3002 MIT-MAGIC-COOKIE-1 0501ad.... I wonder if your configuration would have a problem because if ibus-xkb crashes due to no display, ibus panel could be terminated due to no display before ibus-xkb is executed. So I'd like to ask: - if there is no problem when you run ibus-daemon by manual. - if you have the display permission with xauth list. - if there are any errors in $HOME/.xsession-errors I also recommend to disable selinux if you enabled it. ibus-1.3.7-14.fc14 has been submitted as an update for Fedora 14. https://admin.fedoraproject.org/updates/ibus-1.3.7-14.fc14 I would doubt your configuration. But I modified ibus not to crash when ibus-xkb is executed by manual. I haven't seen the bug reappear. I think it was a corner case, not regular case regarding your questions: - I've logged in using nx in a normal setup after install of FC14. I did not run ibus-daemon manually. Just tried, but no error (using 1.3.7-11) - It might be the problem that nx was not started completely? Again, I was just logging in, not tampering with default $DISPLAY stuff. - I have some errors. But I do not know if they are related because of the time lapse between the report and now: gnome-screensaver: Fatal IO error 11 (Resource temporarily unavailable) on X server :0.0. gnome-settings-daemon: Fatal IO error 11 (Resource temporarily unavailable) on X server :0.0. dropbox: Fatal IO error 11 (Resource temporarily unavailable) on X server :0.0. gdu-notification-daemon: Fatal IO error 11 (Resource temporarily unavailable) on X server :0.0. gnome-volume-control-applet: Fatal IO error 11 (Resource temporarily unavailable) on X server :0.0. gpk-update-icon: Fatal IO error 11 (Resource temporarily unavailable) on X server :0.0. polkit-gnome-authentication-agent-1: Fatal IO error 11 (Resource temporarily unavailable) on X server :0.0. gtk-window-decorator: Fatal IO error 11 (Resource temporarily unavailable) on X server :0.0. abrt-applet: Fatal IO error 11 (Resource temporarily unavailable) on X server :0.0. bluetooth-applet: Fatal IO error 11 (Resource temporarily unavailable) on X server :0.0. nm-applet: Fatal IO error 11 (Resource temporarily unavailable) on X server :0.0. I'll report again if a similar crash happens and relate it to this report. Thanks for lookin into this report. Sorry for the late reply. (In reply to comment #9) > I haven't seen the bug reappear. I think it was a corner case, not regular case OK, it's good to know the bug is not always reproduced. > regarding your questions: > - It might be the problem that nx was not started completely? Again, I was just > logging in, not tampering with default $DISPLAY stuff. Maybe but I'm not sure. I guess the root cause is not ibus. > gnome-screensaver: Fatal IO error 11 (Resource temporarily unavailable) on X > server :0.0. Hmm.., all errors are strange for me. You might see the more information when you would run the applications by manual. > I'll report again if a similar crash happens and relate it to this report. ibus-xkb won't be crashed if you will upgrade to ibus 1.3.7-14 above. However I guess it doesn't fix your root cause and you may see other errors. Thanks. ibus-1.3.7-14.fc14 has been pushed to the Fedora 14 stable repository. If problems still persist, please make note of it in this bug report. |