Description of problem: Got this problem whenever I switch on or restart the laptop. Having this problem since last two updates. Version-Release number of selected component: ibus-1.4.99.20120914-2.fc17 Additional info: libreport version: 2.0.14 abrt_version: 2.0.13 backtrace_rating: 4 cmdline: /usr/libexec/ibus-ui-gtk3 crash_function: panel_switch_engine kernel: 3.5.4-2.fc17.x86_64 truncated backtrace: :Thread no. 1 (7 frames) : #4 panel_switch_engine at panel.c:2730 : #5 panel_update_engines at panel.c:3236 : #6 panel_set_config at panel.c:1358 : #7 emit_signal_instance_in_idle_cb at gdbusconnection.c:3665 : #12 gtk_main at gtkmain.c:1161 : #13 application_run at application.c:218 : #14 application_main at application.c:342
Created attachment 619877 [details] File: core_backtrace
Created attachment 619878 [details] File: environ
Created attachment 619879 [details] File: backtrace
Created attachment 619880 [details] File: limits
Created attachment 619881 [details] File: cgroup
Created attachment 619882 [details] File: maps
Created attachment 619883 [details] File: dso_list
Created attachment 619884 [details] File: var_log_messages
Created attachment 619885 [details] File: open_fds
(In reply to comment #3) > Created attachment 619879 [details] > File: backtrace > #3 0x000000318ba68ed4 in g_assertion_message_expr (domain=domain@entry=0x41b2bd "IBUS", file=file@entry=0x41ca10 "panel.c", line=line@entry=2730, func=func@entry=0x41cf30 "panel_switch_engine", expr=expr@entry=0x41cbcc "_tmp4_") at gtestutils.c:1872 > s = <optimized out> > #4 0x0000000000413a4f in panel_switch_engine (self=0x23c2480, i=<optimized out>, force=<optimized out>) at panel.c:2730 > #5 0x0000000000414209 in panel_update_engines (self=self@entry=0x23c2480, var_engines=var_engines@entry=0x7fbdbc1d5790, var_order=var_order@entry=0x7fbdbc1d6b90) at panel.c:3236 ... > _tmp33__length1 = 1 ... I cannot reproduce your problem. It seems ibus_bus_get_engines_by_names(bus, ["xkb:us::eng"]) returns the null list in your stack. Are you able to reproduce your problem with a new user account instead of the current user account? You might not restart ibus or the dconf value /desktop/ibus/general/preload-engines might be wrong. % dconf read /desktop/ibus/general/preload-engines ['xkb:us::eng', 'anthy',]
Iḿ not facing the problem with a new user account. When I started ibus hangul preferences under new user, it showing error as <<IBus daemon is not running. Hangul engine settings cannot be saved>> Itś dconf value for preload-engines reads as [] I disabled ibus from gnome-session-properties in my current user account and now Iḿ not facing the problem.
(In reply to comment #11) > <<IBus daemon is not running. > Hangul engine settings cannot be saved>> > Itś dconf value for preload-engines reads as [] I'm asking if you see your problem with a new user account when ibus-daemon *is running*.
I'm not facing the error with new user account. I think I messed up with my ibus settings. I reseted ibus by deleting config files from <<.config>> folder. Now I don't have the problem. Thanks
(In reply to comment #13) > I'm not facing the error with new user account. I think I messed up with my > ibus settings. I reseted ibus by deleting config files from <<.config>> > folder. Now I don't have the problem. > Thanks OK, you might not have the write permission under .config/ibus due to changed user id. I think your problem is not happened generally. Please comment here if you notice the difference between the old .config and new one.
(In reply to comment #14) > (In reply to comment #13) > > I'm not facing the error with new user account. I think I messed up with my > > ibus settings. I reseted ibus by deleting config files from <<.config>> > > folder. Now I don't have the problem. > > Thanks > > OK, you might not have the write permission under .config/ibus due to > changed user id. Or your specific preference might caused your problem. If you notice the difference of running 'dconf dump /' between the old .config/dconf/user and the new one, please comment here.
I have installed Fedora 17 on two different laptops from two different manufacturers and I am getting this error every time each laptop boots up. These are straight out of the box installs. I have not altered the configuration of anything. Something is not right with ibus.
I am also getting it immediately on login Fedora 17, Lenovo R61i .config/ibus belongs to me and has user rwx permissions and no access at all for group or world. The one file in .config/ibus - 2523deb844d38aebf8b8778900000010-unix-0 belongs to me. User has rw permissions while group and works are read only.
(In reply to comment #16) > I have installed Fedora 17 on two different laptops from two different > manufacturers and I am getting this error every time each laptop boots up. > These are straight out of the box installs. I have not altered the > configuration of anything. Something is not right with ibus. Did you try with a new user account instead of the current user one? If you don't see any problems with a new user account, probably the dconf value has no-existent engines and it would be good clean up your dconf data. % dconf read /desktop/ibus/general/preload-engines % dconf reset /desktop/ibus/general/preload-engines % ibus-daemon --xim --replace --cache refresh & (In reply to comment #17) > I am also getting it immediately on login Fedora 17, Lenovo R61i > > .config/ibus belongs to me and has user rwx permissions and no access at all > for group or world. > > The one file in .config/ibus - 2523deb844d38aebf8b8778900000010-unix-0 > belongs to me. User has rw permissions while group and works are read only. That file is not used by dconf. It's a right permission. dconf data is $HOME/.config/dconf/user
I did try adding a new user account as suggested in previous posts, but it did not fix the problem. Running the commands provided by fujiwara appears to have fixed the problem on both of my machines. So thank you fujiwara for the solution! The fact remains, however, that this was a problem for me with two fresh (unaltered) builds of Fedora. I personally had never used ibus before and never messed with its configuration. So unless we think it acceptable that everyone who builds a Fedora box should get have to troubleshoot ibus issues, it would be nice to figure out what the root cause of the problem was.
I tried the commands: % dconf read /desktop/ibus/general/preload-engines % dconf reset /desktop/ibus/general/preload-engines % ibus-daemon --xim --replace --cache refresh & as suggested by fujiwara but they didn't work for me. The first two ran to completion, but the 'ibus-daemon' command seemed to hang and when, some time later, I jogged out and in again the ibus crash happened again immediateld after the login completed.
I spoke too soon. ibus failed on the next reboot of both machines. I give up. I will just turn it off.
(In reply to comment #20) Did you install the latest ibus? # yum install ibus It would be good to see the verbose log after terminate ibus with right click on ibus icon and choosing "Quit": % ibus-daemon --xim --verbose
Yes. I run "yum upgrade" pretty regularly and have been through at least a couple of updates of ibus that I can recall. The problem persisted after each update. I will capture a verbose log and post it soon. Thanks.
When I start ibus-daemon in verbose mode, I immediately see the following: (ibus-ui-gtk3:9003): IBUS-WARNING **: ibus_bus_call_sync: org.freedesktop.IBus.GetGlobalEngine: GDBus.Error:org.freedesktop.DBus.Error.Failed: No global engine. No error is thrown when I quit the application.
I am running ibus version 1.5.1.
(In reply to comment #24) > (ibus-ui-gtk3:9003): IBUS-WARNING **: ibus_bus_call_sync: > org.freedesktop.IBus.GetGlobalEngine: > GDBus.Error:org.freedesktop.DBus.Error.Failed: No global engine. The warning is an expected result and not a problem. Do you talk about this bug? I think abrt shows the following errors and ibus verbose mode shows the similar errors in this bug: > (In reply to comment #3) > Created attachment 619879 [details] > File: backtrace > #0 0x000000318be35925 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 > resultvar = 0 > pid = 1354 > selftid = 1354 > #1 0x000000318be370d8 in __GI_abort () at abort.c:91 > save_stage = 2 > act = {__sigaction_handler = {sa_handler = 0x2958be0, sa_sigaction = 0x2958be0}, sa_mask = {__val = {0, 212799189632, 212791780068, 5, 0, 212800138344, 6845471435946078691, 39408928, 212799189632, 72, 212791806229, 0, 0, 212803979072, 4294967295, 212803979040}}, sa_flags = 1, sa_restorer = 0} > sigs = {__val = {32, 0 <repeats 15 times>}} > #2 0x000000318ba689b7 in g_assertion_message (domain=domain@entry=0x41b2bd "IBUS", file=file@entry=0x41ca10 "panel.c", line=line@entry=2730, func=func@entry=0x41cf30 "panel_switch_engine", message=<optimized out>) at gtestutils.c:1861 > lstr = "2730\000\177\000\000\000D~\205\377\177\000\000\310\252\240\213\061\000\000\000\314\313A\000\000\000\000" > s = 0x2595520 "" > #3 0x000000318ba68ed4 in g_assertion_message_expr (domain=domain@entry=0x41b2bd "IBUS", file=file@entry=0x41ca10 "panel.c", line=line@entry=2730, func=func@entry=0x41cf30 "panel_switch_engine", expr=expr@entry=0x41cbcc "_tmp4_") at gtestutils.c:1872 > s = <optimized out> > #4 0x0000000000413a4f in panel_switch_engine (self=0x23c2480, i=<optimized out>, force=<optimized out>) at panel.c:2730 > _tmp0_ = <optimized out> > _tmp1_ = <optimized out> > _tmp4_ = <optimized out> > _tmp5_ = 0 > _tmp6_ = <optimized out> > _tmp8_ = <optimized out> > _tmp9__length1 = <optimized out> > _tmp10_ = <optimized out> > engine = <optimized out> > _tmp14_ = <optimized out> > _tmp19_ = <optimized out>