Bug 1283406

Created attachment 1096341 [details]
File: backtrace

Created attachment 1096342 [details]
File: cgroup

Created attachment 1096343 [details]
File: core_backtrace

Created attachment 1096344 [details]
File: dso_list

Created attachment 1096345 [details]
File: environ

Created attachment 1096346 [details]
File: limits

Created attachment 1096347 [details]
File: maps

Created attachment 1096348 [details]
File: mountinfo

Created attachment 1096349 [details]
File: namespaces

Created attachment 1096350 [details]
File: open_fds

Created attachment 1096351 [details]
File: proc_pid_status

Created attachment 1096352 [details]
File: var_log_messages

This seems to be Waland related.

Just to clarify, I get this error anytime I logout/login into the user session.

I cannot reproduce your problem in F24.

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

#0  0x00007f8d906c3598 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:54
#1  0x00007f8d906c519a in __GI_abort () at abort.c:89
#2  0x00007f8d90ce1e65 in g_assertion_message (domain=domain@entry=0x56381101bb3a "IBUS", file=file@entry=0x56381101bfe6 "dbusimpl.c", line=line@entry=1242, func=func@entry=0x56381101c8a0 <__func__.26124> "bus_dbus_impl_name_owner_changed", message=message@entry=0x5638125ad880 "assertion failed: (old_owner != NULL)") at gtestutils.c:2429
#3  0x00007f8d90ce1efa in g_assertion_message_expr (domain=domain@entry=0x56381101bb3a "IBUS", file=file@entry=0x56381101bfe6 "dbusimpl.c", line=line@entry=1242, func=func@entry=0x56381101c8a0 <__func__.26124> "bus_dbus_impl_name_owner_changed", expr=expr@entry=0x56381101c0f2 "old_owner != NULL") at gtestutils.c:2444
#4  0x000056381100b936 in bus_dbus_impl_name_owner_changed (dbus=0x563812533040, connection=<optimized out>, name=0x563812603b70 "org.freedesktop.IBus.Panel", old_owner=0x0, new_owner=0x563812603a80 ":1.7") at dbusimpl.c:1242
#5  0x00007f8d90fbc995 in g_closure_invoke (closure=closure@entry=0x563812529f90, return_value=return_value@entry=0x0, n_param_values=5, param_values=param_values@entry=0x7ffe612ccaf0, invocation_hint=invocation_hint@entry=0x7ffe612cca70) at gclosure.c:801
#6  0x00007f8d90fcf04c in signal_emit_unlocked_R (node=node@entry=0x56381252d7a0, detail=detail@entry=0, instance=instance@entry=0x563812533040, emission_return=emission_return@entry=0x0, instance_and_params=instance_and_params@entry=0x7ffe612ccaf0) at gsignal.c:3557
#7  0x00007f8d90fd84c0 in g_signal_emit_valist (instance=<optimized out>, signal_id=<optimized out>, detail=<optimized out>, var_args=var_args@entry=0x7ffe612ccd10) at gsignal.c:3383
#8  0x00007f8d90fd888f in g_signal_emit (instance=instance@entry=0x563812533040, signal_id=<optimized out>, detail=detail@entry=0) at gsignal.c:3439
#9  0x000056381100a462 in bus_name_service_set_primary_owner (dbus=0x563812533040, owner=0x563812548460, service=0x563812548630) at dbusimpl.c:368
#10 bus_dbus_impl_request_name (dbus=0x563812533040, connection=<optimized out>, parameters=<optimized out>, invocation=<optimized out>) at dbusimpl.c:1076
#11 0x00007f8d912da739 in call_in_idle_cb (user_data=<optimized out>) at gdbusconnection.c:4832
#12 0x00007f8d90cbc07a in g_main_dispatch (context=0x563812513920) at gmain.c:3154
#13 g_main_context_dispatch (context=context@entry=0x563812513920) at gmain.c:3769
#14 0x00007f8d90cbc410 in g_main_context_iterate (context=0x563812513920, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at gmain.c:3840
#15 0x00007f8d90cbc732 in g_main_loop_run (loop=0x5638125a5b30) at gmain.c:4034
#16 0x00005638110192c0 in bus_server_run () at server.c:143
#17 0x0000563811007a9e in main (argc=1, argv=0x7ffe612cd148) at main.c:279

(In reply to Vít Ondruch from comment #13)
> This seems to be Waland related.

I tried GNOME Wayland but not problem.

Did you try a new user account instead of the existent current user one?

(In reply to fujiwara from comment #16)
> Did you try a new user account instead of the existent current user one?

Current one. What should be the difference?

(In reply to Vít Ondruch from comment #17)
> (In reply to fujiwara from comment #16)
> > Did you try a new user account instead of the existent current user one?
> 
> Current one. What should be the difference?

If the new account does not reproduce your problem, some of your settings could causes your problem.

This bug appears to have been reported against 'rawhide' during the Fedora 24 development cycle.
Changing version to '24'.

More information and reason for this action is here:
https://fedoraproject.org/wiki/Fedora_Program_Management/HouseKeeping/Fedora24#Rawhide_Rebase

Please comment here again if you will find the reproducing steps.

Similar problem has been detected:

crash after login to GNOME session

reporter:       libreport-2.7.1
backtrace_rating: 4
cmdline:        /usr/bin/ibus-daemon -r --xim
crash_function: bus_dbus_impl_name_owner_changed
executable:     /usr/bin/ibus-daemon
global_pid:     1879
kernel:         4.5.7-300.fc24.x86_64
package:        ibus-1.5.13-1.fc24
pkg_fingerprint: 73BD E983 81B4 6521
pkg_vendor:     Fedora Project
reason:         ibus-daemon killed by SIGABRT
reproducible:   Not sure how to reproduce the problem
runlevel:       N 5
type:           CCpp
uid:            1000

Seen here too. Doesn't crash from a new clean account.

Correction: it crashes under GNOME Wayland even with a clean account (I got the trace from bug 1350111, so the two bugs are probably related). Therefore user settings are not the problem.

Doesn't seem to happen anymore with latest updates.

Similar problem has been detected:

This crash occured at the same time as Bug 1353702

reporter:       libreport-2.7.1
backtrace_rating: 4
cmdline:        /usr/bin/ibus-daemon -r --xim
crash_function: bus_dbus_impl_name_owner_changed
executable:     /usr/bin/ibus-daemon
global_pid:     2692
kernel:         4.6.3-300.fc24.x86_64
package:        ibus-1.5.13-3.fc24
pkg_fingerprint: 73BD E983 81B4 6521
pkg_vendor:     Fedora Project
reason:         ibus-daemon killed by SIGABRT
reproducible:   Not sure how to reproduce the problem
runlevel:       N 5
type:           CCpp
uid:            1000

So, yes re Comment 23 these bugs do seem related and re Comment 24 no, it does seem to be happening with the latest updates.

Bug 1353702 might be considered a dup of this bug in addition to Bug 1350111.

Created attachment 1177419 [details]
'problem's data directory' re Comment 25