Created attachment 832460 [details]
File: backtrace

Created attachment 832461 [details]
File: cgroup

Created attachment 832462 [details]
File: core_backtrace

Created attachment 832463 [details]
File: dso_list

Created attachment 832464 [details]
File: environ

Created attachment 832465 [details]
File: limits

Created attachment 832466 [details]
File: maps

Created attachment 832467 [details]
File: open_fds

Created attachment 832468 [details]
File: proc_pid_status

Created attachment 832469 [details]
File: var_log_messages

Created attachment 832474 [details]
screenshot

As you can see from the screenshot,the cursor is far away from the letter.Besides,I'm unable to type Chinese

The some bug happens,after the Korean KDE install

(In reply to lnie from comment #1)
> Created attachment 832460 [details]
> File: backtrace

I cannot reproduce your backtrace.

Would you show the result of the following command?

% gsettings get org.freedesktop.ibus.general preload-engines
['xkb:us::eng']

Are you able to see your problem with a new user account instead of the current user account?

Just do a Chinese KDE install,the bug will show up.

bug still occurs with new user.

the output of gsettings get org.freedesktop.ibus.general preload-engines
['xkb:us::eng'] is:
 no that key:['xkb:us::eng']

FYI: tested with TC5,bug persists

added one,Chinese Gnome install works fine

Would you show the result of the following command?

% setxkbmap -query

I'd like to ask to replace /usr/libexec/ibus-ui-gtk3 with the following file:
http://fujiwara.fedorapeople.org/ibus/20131206/ibus-ui-gtk3

# mv /usr/libexec/ibus-ui-gtk3 /usr/libexec/ibus-ui-gtk3.orig
# wget -O /usr/libexec/ibus-ui-gtk3 \
    http://fujiwara.fedorapeople.org/ibus/20131206/ibus-ui-gtk3
# chmod a+x /usr/libexec/ibus-ui-gtk3


And I'd like to see debug messages with the following commands when you see your problem:
% ibus quit
% ibus-daemon --verbose --xim

run wget-O command in a chinese KDE system,get the follow output:
the address "http://fujiwara.fedorapeople.org/ibus/20131206/ibus-ui-gtk3"
lacks of protocol type

while run that same command in an English KDE system,get the follow different output:
/usr/libexec/ibus-ui-gtk3:Permission denied

the setxkmap -query's output without the replacement is:
rules:evdev
model:evdev
layout:cn

the output of ibus quit:
quit is an unkown command

the output of ibus-daemon --verbose --xim has been attached.

I think I need to emphasize that -every time- you restart the system,the bug will
show up,and just stay there.

Created attachment 834207 [details]
ibuscreenshot

You can see from the screenshot that the system just hang there.
FYI: the sreenshot was taken the first time I run that command,
after a restart ,I run that same command the system just hang there 
without any output,I will attach another screenshot later

Created attachment 834208 [details]
another one

(In reply to lnie from comment #18)
> while run that same command in an English KDE system,get the follow
> different output:
> /usr/libexec/ibus-ui-gtk3:Permission denied

You should run the following command with root user.

> (In reply to fujiwara from comment #17)
> > # mv /usr/libexec/ibus-ui-gtk3 /usr/libexec/ibus-ui-gtk3.orig
> > # wget -O /usr/libexec/ibus-ui-gtk3 \
> >     http://fujiwara.fedorapeople.org/ibus/20131206/ibus-ui-gtk3
> > # chmod a+x /usr/libexec/ibus-ui-gtk3


> the setxkmap -query's output without the replacement is:
> rules:evdev
> model:evdev
> layout:cn

OK, probably this is the root cause.
But it's still good to get the verbose log after you replace ibus-ui-gtk3 above.

> the output of ibus quit:
> quit is an unkown command

It was my mistake. Please try 'ibus exit' instead of 'ibus quit'.

% ibus exit

(In reply to fujiwara from comment #22)

> OK, probably this is the root cause.
> But it's still good to get the verbose log after you replace ibus-ui-gtk3
> above.
> 
as I said in #comment18,
run wget-O command in a chinese KDE system,get the follow output:
the address "http://fujiwara.fedorapeople.org/ibus/20131206/ibus-ui-gtk3"
lacks of protocol type
so,I'm unable to do the replacement.
> > the output of ibus quit:
> > quit is an unkown command
> 
> It was my mistake. Please try 'ibus exit' instead of 'ibus quit'.
> 
> % ibus exit

the output of ibus exit is nothing

(In reply to lnie from comment #23)
> as I said in #comment18,
> run wget-O command in a chinese KDE system,get the follow output:
> the address "http://fujiwara.fedorapeople.org/ibus/20131206/ibus-ui-gtk3"
> lacks of protocol type
> so,I'm unable to do the replacement.

Probably you didn't set up DNS.
I guess your box needs dhcp.

% ping fujiwara.fedorapeople.org

> > > the output of ibus quit:
> > > quit is an unkown command
> > 
> > It was my mistake. Please try 'ibus exit' instead of 'ibus quit'.
> > 
> > % ibus exit
> 
> the output of ibus exit is nothing


Right, this command can terminate the process of ibus-daemon with the command line before you run ibus-daemon newly.

(In reply to fujiwara from comment #24)
> (In reply to lnie from comment #23)
> > as I said in #comment18,
> > run wget-O command in a chinese KDE system,get the follow output:
> > the address "http://fujiwara.fedorapeople.org/ibus/20131206/ibus-ui-gtk3"
> > lacks of protocol type
> > so,I'm unable to do the replacement.
> 
> Probably you didn't set up DNS.
> I guess your box needs dhcp.
> 
> % ping fujiwara.fedorapeople.org

 ping successfully
> 
> > > > the output of ibus quit:
> > > > quit is an unkown command
> > > 
> > > It was my mistake. Please try 'ibus exit' instead of 'ibus quit'.
> > > 
> > > % ibus exit
> > 
> > the output of ibus exit is nothing
> 
> 
> Right, this command can terminate the process of ibus-daemon with the
> command line before you run ibus-daemon newly.

(In reply to lnie from comment #25)
> (In reply to fujiwara from comment #24)
> > (In reply to lnie from comment #23)
> > > as I said in #comment18,
> > > run wget-O command in a chinese KDE system,get the follow output:
> > > the address "http://fujiwara.fedorapeople.org/ibus/20131206/ibus-ui-gtk3"
> > > lacks of protocol type
> > > so,I'm unable to do the replacement.
> > 
> > Probably you didn't set up DNS.
> > I guess your box needs dhcp.
> > 
> > % ping fujiwara.fedorapeople.org
> 
>  ping successfully
> > 

Hmm.., I searched the string of "lacks of protocol type" in the source code of wget and wget has no such a string and also no clue with google.
Probably the error is not caused by wget.

Can you get http://fujiwara.fedorapeople.org/ibus/20131206/ibus-ui-gtk3 with firefox ?

(In reply to fujiwara from comment #17)
> # mv /usr/libexec/ibus-ui-gtk3 /usr/libexec/ibus-ui-gtk3.orig
> # wget -O /usr/libexec/ibus-ui-gtk3 \
>     http://fujiwara.fedorapeople.org/ibus/20131206/ibus-ui-gtk3
> # chmod a+x /usr/libexec/ibus-ui-gtk3
> 
> 
by the above words,you want me to do is :
wget ibus-ui-gtks from http://fujiwara.../ibus-ui-gtk3
and then replace the default one with that one,
yes?
if so,
then I can do the replacement,as I can
get that ibus-ui-gtk3 using wget http://../ibus-ui-gtk3

(In reply to fujiwara from comment #26)
> (In reply to lnie from comment #25)
> > (In reply to fujiwara from comment #24)
> > > (In reply to lnie from comment #23)
> > > > as I said in #comment18,
> > > > run wget-O command in a chinese KDE system,get the follow output:
> > > > the address "http://fujiwara.fedorapeople.org/ibus/20131206/ibus-ui-gtk3"
> > > > lacks of protocol type
> > > > so,I'm unable to do the replacement.
> > > 
> > > Probably you didn't set up DNS.
> > > I guess your box needs dhcp.
> > > 
> > > % ping fujiwara.fedorapeople.org
> > 
> >  ping successfully
> > > 
> 
> Hmm.., I searched the string of "lacks of protocol type" in the source code
> of wget and wget has no such a string and also no clue with google.

 yeah,I translate the Chinese output to English,so.. 
> Probably the error is not caused by wget.
> 
> Can you get http://fujiwara.fedorapeople.org/ibus/20131206/ibus-ui-gtk3 with
> firefox ?

yes

yes,I can get that with firefox,see #com27

(In reply to lnie from comment #27)
> (In reply to fujiwara from comment #17)
> > # mv /usr/libexec/ibus-ui-gtk3 /usr/libexec/ibus-ui-gtk3.orig
> > # wget -O /usr/libexec/ibus-ui-gtk3 \
> >     http://fujiwara.fedorapeople.org/ibus/20131206/ibus-ui-gtk3
> > # chmod a+x /usr/libexec/ibus-ui-gtk3
> > 
> > 
> by the above words,you want me to do is :
> wget ibus-ui-gtks from http://fujiwara.../ibus-ui-gtk3
> and then replace the default one with that one,
> yes?
> if so,
> then I can do the replacement,as I can
> get that ibus-ui-gtk3 using wget http://../ibus-ui-gtk3

Yes, I do. Please try it.

(In reply to lnie from comment #29)
> yes,I can get that with firefox,see #com27

% ibus exit
And replace /usr/libexec/ibus-ui-gtk3 with the new file with root user.
% ibus-daemon --xim --verbose


(In reply to lnie from comment #28)
>  yeah,I translate the Chinese output to English,so.. 

I think you could run 'env LC_MESSAGES=C wget ...' to get the English error message.

(In reply to fujiwara from comment #30)
> (In reply to lnie from comment #27)
> > (In reply to fujiwara from comment #17)
> > > # mv /usr/libexec/ibus-ui-gtk3 /usr/libexec/ibus-ui-gtk3.orig
> > > # wget -O /usr/libexec/ibus-ui-gtk3 \
> > >     http://fujiwara.fedorapeople.org/ibus/20131206/ibus-ui-gtk3
> > > # chmod a+x /usr/libexec/ibus-ui-gtk3
> > > 
> > > 
> > by the above words,you want me to do is :
> > wget ibus-ui-gtks from http://fujiwara.../ibus-ui-gtk3
> > and then replace the default one with that one,
> > yes?
> > if so,
> > then I can do the replacement,as I can
> > get that ibus-ui-gtk3 using wget http://../ibus-ui-gtk3
> 
> Yes, I do. Please try it.
> 
> (In reply to lnie from comment #29)
> > yes,I can get that with firefox,see #com27
> 
> % ibus exit

 It's weird, this time the output of'ibus exit'is cann't connect to IBus,
 even on English KDE system with root user
 
> I think you could run 'env LC_MESSAGES=C wget ...' to get the English error
> message.
 Thanks for your helpful message

(In reply to lnie from comment #31)
> > % ibus exit
> 
>  It's weird, this time the output of'ibus exit'is cann't connect to IBus,
>  even on English KDE system with root user

Because probably ibus was not running then.
If ibus is not running, you don't have to run 'ibus exit'.

(In reply to fujiwara from comment #30)
> % ibus exit
> And replace /usr/libexec/ibus-ui-gtk3 with the new file with root user.
> % ibus-daemon --xim --verbose

Can you attach the output of the ibus-daemon?

(In reply to fujiwara from comment #32)
> (In reply to lnie from comment #31)
> > > % ibus exit
> > 
> >  It's weird, this time the output of'ibus exit'is cann't connect to IBus,
> >  even on English KDE system with root user
> 
> Because probably ibus was not running then.
> If ibus is not running, you don't have to run 'ibus exit'.

ibus-daemon runs per process and 'ibus exit' works with the current user account but not root account.

> 
> (In reply to fujiwara from comment #30)
> > % ibus exit
> > And replace /usr/libexec/ibus-ui-gtk3 with the new file with root user.
> > % ibus-daemon --xim --verbose
> 
> Can you attach the output of the ibus-daemon?

Created attachment 834650 [details]
result

(In reply to lnie from comment #34)
> Created attachment 834650 [details]
> result

as you can see from the screenshot,the system just hangs there

> ibus-daemon runs per process and 'ibus exit' works with the current user
> account but not root account.
> 
ibus exit show the same output with current user

(In reply to lnie from comment #35)
> (In reply to lnie from comment #34)
> > Created attachment 834650 [details]
> > result
> 
> as you can see from the screenshot,the system just hangs there

From your log, I think you don't reproduce your backtrace as I noted in comment #14 :

> (In reply to fujiwara from comment #14)
> > (In reply to lnie from comment #1)
> > > Created attachment 832460 [details]
> > > File: backtrace
> > 
> > I cannot reproduce your backtrace.
> > 

Are you still reproduce your backtrace?

If yes, please try the follwing step:
1. Run im-chooser and disable ibus.
2. Log out and in the session again.
3. Run 'ibus-daemon --xim --verbose'


BTW, your log shows "Locale not supported by C library."
You should run 'env LANG=C ...' instead of 'env LANG=c ...'.

Probably I think your hang issue is a different bug.

(In reply to fujiwara from comment #37)
> (In reply to lnie from comment #35)
> > (In reply to lnie from comment #34)
> > > Created attachment 834650 [details]
> > > result
> > 
> > as you can see from the screenshot,the system just hangs there
> 
> From your log, I think you don't reproduce your backtrace as I noted in
> comment #14 :

yes,but in #comment32,you ask me to 
 'Can you attach the output of the ibus-daemon?'
  then I attach the output of ibus-daemon --xim --verbose
> 
> > (In reply to fujiwara from comment #14)
> > > (In reply to lnie from comment #1)
> > > > Created attachment 832460 [details]
> > > > File: backtrace
> > > 
> > > I cannot reproduce your backtrace.
> > > 
> 
> Are you still reproduce your backtrace?
> 
> If yes, please try the follwing step:
> 1. Run im-chooser and disable ibus.
> 2. Log out and in the session again.
> 3. Run 'ibus-daemon --xim --verbose'
> 
 the result after run im-chooser will be attached

> BTW, your log shows "Locale not supported by C library."
> You should run 'env LANG=C ...' instead of 'env LANG=c ...'.
>
That dosen't matter,right?As you may know,the output of
"env LANG=c ....",and "env LANG=C...."are the same. 
> Probably I think your hang issue is a different bug.

Created attachment 834669 [details]
start

Created attachment 834670 [details]
end

I taken two screenshots ,as you can see,im-chooser just hangs there

Created attachment 834674 [details]
output of im-chooser

Now I can reproduced your backtrace when the session XKB is 'cn':

> the setxkmap -query's output without the replacement is:
> rules:evdev
> model:evdev
> layout:cn

I put the fixed /usr/bin/ibus-daemon :
http://fujiwara.fedorapeople.org/ibus/20131206/ibus-daemon

If you replace ibus-daemon, you won't reproduce your backtrace.

Regarding to your hang problem, it's another bug.

Can you open another bug?
You can get back the original ibus-ui-gtk3 and put report the logs of "ibus-daemon --xim --verbose" and "im-chooser" with C locale.

It seems any applications which uses dbus failed in your box and maybe dbus is not configured.

Attached the patch to fix the backtrace:

--- ibus-1.5.4/bus/ibusimpl.c.orig
+++ ibus-1.5.4/bus/ibusimpl.c
@@ -1135,7 +1135,17 @@ _ibus_get_engines_by_names (BusIBusImpl
     g_variant_builder_init (&builder, G_VARIANT_TYPE ("av"));
     while (names[i] != NULL) {
         IBusEngineDesc *desc = (IBusEngineDesc *) g_hash_table_lookup (
-                ibus->engine_table, names[i++]);
+                ibus->engine_table, names[i]);
+
+        /* preload engines return user XKB so if the engine does not
+         * exist in simple.xml, fall back to 'us' layout. */
+        if (desc == NULL && g_str_has_prefix (names[i], "xkb:")) {
+            desc = (IBusEngineDesc *) g_hash_table_lookup (
+                    ibus->engine_table, "xkb:us::eng");
+        }
+
+        i++;
+
         if (desc == NULL)
             continue;
         g_variant_builder_add (

I searched your log about "failed to commit changes to dconf: The connection is closed" in ibus-daemon and hit bug 975521 .
SELinux maybe possible.

> I put the fixed /usr/bin/ibus-daemon :
> http://fujiwara.fedorapeople.org/ibus/20131206/ibus-daemon
> 
> If you replace ibus-daemon, you won't reproduce your backtrace.
> 
 What the supposed result after the replacement with your ibus-daemon?
 It seems that nothing changed except that a notification box that says:Super+Space is now the default hotkey comes out 

> Regarding to your hang problem, it's another bug.
> 
> Can you open another bug?
 open one #bug1040278 :)

(In reply to lnie from comment #45)
> > I put the fixed /usr/bin/ibus-daemon :
> > http://fujiwara.fedorapeople.org/ibus/20131206/ibus-daemon
> > 
> > If you replace ibus-daemon, you won't reproduce your backtrace.
> > 
>  What the supposed result after the replacement with your ibus-daemon?
>  It seems that nothing changed except that a notification box that
> says:Super+Space is now the default hotkey comes out 

I guess you may always get the notification message because of your dbus + hang problem.

> 
> > Regarding to your hang problem, it's another bug.
> > 
> > Can you open another bug?
>  open one #bug1040278 :)

OK, thanks.
BTW, ibus-daemon and ibus should be run by the current user account but not root account.

https://github.com/fujiwarat/ibus/commit/fe84a063f8049a4365938336359ebbe6c133f94f

*** Bug 1039691 has been marked as a duplicate of this bug. ***

*** Bug 1004006 has been marked as a duplicate of this bug. ***

I just wonder if your hang issue is fixed when ibus-daemon runs with the current user account.
This patch fixes the SEGV and I don't see any hang issues.

(In reply to fujiwara from comment #50)
> I just wonder if your hang issue is fixed when ibus-daemon runs with the
> current user account.
> This patch fixes the SEGV and I don't see any hang issues.

Nope,still there

Tested with RC1,still there. After replacement of ibus-daemon,'The assertion failure of '(i >= 0 && i < m_engine.length)'seems gone,but the system still hangs

Created attachment 836118 [details]
screenshot

Created attachment 836171 [details]
Fedora Live KDE RC1 with ibus-libpinyin

I tried Live KDE RC1;Fedora-Live-KDE-x86_64-20-1.iso but I cannot reproduce your hang.
Note: need to install ibus since Live KDE does not install ibus by default.

When you run 'ibus exit', your hang does not appear?
When you stop ibus with im-chooser, your hang does not appear?
Your hang is not reproduced in GNOME?
Do you have any messages in /var/log/messages ?
How about running 'top' command?

Note: the warning of "No global engine." is no problem.

Also your hang is reproduced with a new user account besides the current user account?
(I asked the same question but now I need to separate the problems of hang and backtrace(assertion failure).

(In reply to fujiwara from comment #54)
> Created attachment 836171 [details]
> Fedora Live KDE RC1 with ibus-libpinyin
> 
> I tried Live KDE RC1;Fedora-Live-KDE-x86_64-20-1.iso but I cannot reproduce
> your hang.
> Note: need to install ibus since Live KDE does not install ibus by default.
> 
> When you run 'ibus exit', your hang does not appear?
  No hang
> When you stop ibus with im-chooser, your hang does not appear?
  As you can see from the attachments,unable to stop ibus with im-chooser in 
  Chinese KDE system,only able to do it in English system  
> Your hang is not reproduced in GNOME?
  able to produce it
> Do you have any messages in /var/log/messages ?
> How about running 'top' command?
   will be attached 

FYI:I have done all the test with a new user account

Created attachment 836209 [details]
top messages

Created attachment 836210 [details]
/var/log/messages

Created attachment 836211 [details]
screenshot with chinese

Created attachment 836212 [details]
screenshot with English

(In reply to lnie from comment #60)
> Created attachment 836212 [details]
> screenshot with English

oh,it's my bad.when I try to logout ibus in English system,the logout button is disabled as in Chinese system

Can you describe how to reproduce your hang with step by step?

(In reply to lnie from comment #56)
> > When you stop ibus with im-chooser, your hang does not appear?
>   As you can see from the attachments,unable to stop ibus with im-chooser in 
>   Chinese KDE system,only able to do it in English system  

I don't know if the Chinese KDE hangs from the screenshot in comment 59.

> > Do you have any messages in /var/log/messages ?
> > How about running 'top' command?

OK, I don't see any errors during your hang from your attachements.

> FYI:I have done all the test with a new user account

Do you mean you can reproduce your hang with a new user account?


Are you able to provide the access of your desktop and root privilege to me?
'vino-preference' command can give the permission with IP address.

# yum install vino

(In reply to lnie from comment #61)
> (In reply to lnie from comment #60)
> > Created attachment 836212 [details]
> > screenshot with English
> 
> oh,it's my bad.when I try to logout ibus in English system,the logout button
> is disabled as in Chinese system

It would be a bug in accountsservice in the first login. At the moment, you could reboot your system or kill ksmserver .

(In reply to fujiwara from comment #62)
> Can you describe how to reproduce your hang with step by step?
> 
 just one step and as you asked, run 'ibus-daemon --xim --verbose' with new user

 okay,maybe you want to know something like the following:
 I add one new user in the original user
 then start a new session and type the new user and password.
 then replace the ibus-daemon
 then run 'ibus-daemon --xim--verbose'with the current user
> (In reply to lnie from comment #56)
> > > When you stop ibus with im-chooser, your hang does not appear?
> >   As you can see from the attachments,unable to stop ibus with im-chooser in 
> >   Chinese KDE system,only able to do it in English system  
> 
> I don't know if the Chinese KDE hangs from the screenshot in comment 59.
  No hang
> 
> > FYI:I have done all the test with a new user account
> 
> Do you mean you can reproduce your hang with a new user account?
  yes,of course.see the reproduce steps

(In reply to lnie from comment #63)
> (In reply to fujiwara from comment #62)
> > Can you describe how to reproduce your hang with step by step?
> > 
>  just one step and as you asked, run 'ibus-daemon --xim --verbose' with new
> user
> 
>  okay,maybe you want to know something like the following:
>  I add one new user in the original user
>  then start a new session and type the new user and password.
>  then replace the ibus-daemon
>  then run 'ibus-daemon --xim--verbose'with the current user

OK, I see.
It seems your desktop hangs whenever you just run ibus-daemon.
But I cannot reproduce it and I cannot find any differences between my desktop and yours.
I'm thinking you might have a special setting to reproduce your hang and it would be a way to understand your problem to access your desktop directly.


Are you able to provide the access of your desktop and root privilege to me?
'vino-preference' command can give the permission with IP address.

You can install vino:
# yum install vino

> > (In reply to lnie from comment #56)
> > > > When you stop ibus with im-chooser, your hang does not appear?
> > >   As you can see from the attachments,unable to stop ibus with im-chooser in 
> > >   Chinese KDE system,only able to do it in English system  
> > 
> > I don't know if the Chinese KDE hangs from the screenshot in comment 59.
>   No hang

Ah, I got it. You might like to kill ksmserver.

> 
> OK, I see.
> It seems your desktop hangs whenever you just run ibus-daemon.
> But I cannot reproduce it and I cannot find any differences between my
> desktop and yours.
> I'm thinking you might have a special setting to reproduce your hang and it
> would be a way to understand your problem to access your desktop directly.

 As I have described,the tested system is a fresh installed one,so I really don't 
 think it's caused by a special setting.Actually,what I really want to be fixed 
 is: ibus crash after the reboot of a fresh installed system,and stay crashed.
 From #Comment48,49,one can know that many people saw this bug.

(In reply to lnie from comment #65)
>  think it's caused by a special setting.Actually,what I really want to be
> fixed 
>  is: ibus crash after the reboot of a fresh installed system,and stay
> crashed.
>  From #Comment48,49,one can know that many people saw this bug.

Comment 48 and 49 are the same backtrace(abort) but not your hang issue.
After this abort will be closed fixed, I will ask to open another bug for your hang.

Did you reproduce your problem with Live KDE RC1?

 Sorry for the late reply,I were downloading the Live KDE RC1.

(In reply to fujiwara from comment #66)
> (In reply to lnie from comment #65)
> >  think it's caused by a special setting.Actually,what I really want to be
> > fixed 
> >  is: ibus crash after the reboot of a fresh installed system,and stay
> > crashed.
> >  From #Comment48,49,one can know that many people saw this bug.
> 
> Comment 48 and 49 are the same backtrace(abort) but not your hang issue.
  I know,and I think it should be fixed first. Maybe after the fix,the hang problem will gone,who knows.
  As for the hang,maybe they will see it the time they run ibus-daemon --xim  --verbose.Maybe you should ask them whether they would like to run that command on their systems?

> Did you reproduce your problem with Live KDE RC1?
   Er,I tested with Live KDE RC1 just now,'ibus-daemon' hang on my VM

(In reply to lnie from comment #67)
>   As for the hang,maybe they will see it the time they run ibus-daemon --xim
> --verbose.Maybe you should ask them whether they would like to run that
> command on their systems?

I don't think so. I think your issue is special.
And I know the abort should not cause any hangs.

> 
> > Did you reproduce your problem with Live KDE RC1?
>    Er,I tested with Live KDE RC1 just now,'ibus-daemon' hang on my VM

And then I have no idea to get your problem.

(In reply to fujiwara from comment #68)
> (In reply to lnie from comment #67)
> >   As for the hang,maybe they will see it the time they run ibus-daemon --xim
> > --verbose.Maybe you should ask them whether they would like to run that
> > command on their systems?
> 
> I don't think so. I think your issue is special.
> And I know the abort should not cause any hangs.
> 
yeah,maybe,so as I said,you should fix the common one

(In reply to lnie from comment #69)
> yeah,maybe,so as I said,you should fix the common one

Probably I don't think your problem is caused by ibus even though it won't happen after ibus exit because I don't see any problems with ibus.
Maybe hardware specific or something.

(In reply to fujiwara from comment #70)
> (In reply to lnie from comment #69)
> > yeah,maybe,so as I said,you should fix the common one
> 
> Probably I don't think your problem is caused by ibus even though it won't
> happen after ibus exit because I don't see any problems with ibus.
> Maybe hardware specific or something.

yeah,maybe,so as I said just fix that common one in #comment48,49.

I just installed Fedora 20

reporter:       libreport-2.1.9
backtrace_rating: 4
cmdline:        /usr/libexec/ibus-ui-gtk3
crash_function: _g_log_abort
executable:     /usr/libexec/ibus-ui-gtk3
kernel:         3.11.10-301.fc20.x86_64
package:        ibus-1.5.4-2.fc20
reason:         Process /usr/libexec/ibus-ui-gtk3 was killed by signal 6 (SIGABRT)
runlevel:       N 5
type:           CCpp
uid:            1000

(In reply to LiZhenbo from comment #72)
> I just installed Fedora 20

You can try the test binary at the moment:
http://fujiwara.fedorapeople.org/ibus/20131206/ibus-daemon

Maybe the next release is January beginning.

(In reply to fujiwara from comment #73)
> (In reply to LiZhenbo from comment #72)
> > I just installed Fedora 20
> 
> You can try the test binary at the moment:
> http://fujiwara.fedorapeople.org/ibus/20131206/ibus-daemon
> 
> Maybe the next release is January beginning.

Would you please explain it a little more?
I don't know how to help to test it.

(In reply to LiZhenbo from comment #74)
> (In reply to fujiwara from comment #73)
> > (In reply to LiZhenbo from comment #72)
> > > I just installed Fedora 20
> > 
> > You can try the test binary at the moment:
> > http://fujiwara.fedorapeople.org/ibus/20131206/ibus-daemon
> > 
> > Maybe the next release is January beginning.
> 
> Would you please explain it a little more?
> I don't know how to help to test it.

After you get ibus-daemon above, you can replace /usr/bin/ibus-daemon with it with root account.
And restarting ibus-daemon with the current user account will fix the problem.

(In reply to fujiwara from comment #75)
> (In reply to LiZhenbo from comment #74)
> > (In reply to fujiwara from comment #73)
> > > (In reply to LiZhenbo from comment #72)
> > > > I just installed Fedora 20
> > > 
> > > You can try the test binary at the moment:
> > > http://fujiwara.fedorapeople.org/ibus/20131206/ibus-daemon
> > > 
> > > Maybe the next release is January beginning.
> > 
> > Would you please explain it a little more?
> > I don't know how to help to test it.
> 
> After you get ibus-daemon above, you can replace /usr/bin/ibus-daemon with
> it with root account.
> And restarting ibus-daemon with the current user account will fix the
> problem.

It works for me, thank you.

ibus-1.5.5-1.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/ibus-1.5.5-1.fc20

ibus-1.5.5-1.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/ibus-1.5.5-1.fc19

Package ibus-1.5.5-1.fc19:
* should fix your issue,
* was pushed to the Fedora 19 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing ibus-1.5.5-1.fc19'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2014-0847/ibus-1.5.5-1.fc19
then log in and leave karma (feedback).

ibus-1.5.5-1.fc20 has been pushed to the Fedora 20 stable repository.  If problems still persist, please make note of it in this bug report.

ibus-1.5.5-1.fc19 has been pushed to the Fedora 19 stable repository.  If problems still persist, please make note of it in this bug report.