Version-Release number of selected component: plymouth-0.8.9-0.2013.03.26.0.fc19 Additional info: reporter: libreport-2.1.6 backtrace_rating: 4 cmdline: @usr/sbin/plymouthd --mode=boot --pid-file=/var/run/plymouth/pid --attach-to-session crash_function: __assert_fail_base executable: /usr/sbin/plymouthd kernel: 3.10.9-200.fc19.x86_64 runlevel: 5 3 uid: 0 var_log_messages: Aug 27 12:41:08 w4r3d abrt[9327]: Saved core dump of pid 9309 (/usr/sbin/plymouthd) to /var/tmp/abrt/ccpp-2013-08-27-12:41:04-9309 (6701056 bytes) Truncated backtrace: Thread no. 1 (8 frames) #2 __assert_fail_base at assert.c:92 #3 __assert_fail at assert.c:101 #4 ply_event_loop_watch_fd at ply-event-loop.c:742 #5 open_input_source at ./plugin.c:691 #6 ply_event_loop_handle_disconnect_for_source at ply-event-loop.c:1089 #7 ply_event_loop_disconnect_source at ply-event-loop.c:1189 #8 ply_event_loop_process_pending_events at ply-event-loop.c:1333 #9 ply_event_loop_run at ply-event-loop.c:1368
Created attachment 791961 [details] File: backtrace
Created attachment 791962 [details] File: cgroup
Created attachment 791963 [details] File: core_backtrace
Created attachment 791964 [details] File: dso_list
Created attachment 791965 [details] File: environ
Created attachment 791966 [details] File: limits
Created attachment 791967 [details] File: maps
Created attachment 791968 [details] File: open_fds
Created attachment 791969 [details] File: proc_pid_status
Created attachment 852401 [details] output of $ ps -A -f I ran into this bug today using plymouth-0.8.9-3.2013.08.14.fc20 kernel-3.12.6-300.fc20.x86_64 and all other updates from F20 "updates" and "updates-testing" This happened when I logged out from my GNOME session using the gnome-shell system menu in the top right corner. After this crash I tty1 was just a black screen (no GDM or Gnome-shell) and I couldn't log in to tty2, tty3, … any more getting this message: "System is booting up. See pam_nologin(8) Authentication failure" Some processes of the user logged in under Gnome where still running (see attachment). Meanwhile gnome-shell stuck at 100% CPU, this is the backtrace: (gdb) bt full #0 0x0000003aaca3814a in g_hash_table_resize (hash_table=hash_table@entry=0x2e54c00) at ghash.c:552 node_hash = 134448496 hash_val = 1 step = 1730710334 new_keys = 0x2e56a30 new_values = 0x2e56b60 new_hashes = 0x2e567c0 old_size = <optimized out> i = <optimized out> #1 0x0000003aaca3854e in g_hash_table_maybe_resize (hash_table=0x2e54c00) at ghash.c:594 noccupied = <optimized out> size = <optimized out> #2 g_hash_table_remove_internal (hash_table=0x2e54c00, key=0x1, notify=1) at ghash.c:1277 node_hash = 2 #3 0x000000342b8cb463 in do_call (client=client@entry=0x260a9f0, call_type=call_type@entry=CALL_TYPE_NAME_VANISHED) at gdbusnamewatching.c:216 current_context = 0xeb6ac0 #4 0x000000342b8cb695 in call_vanished_handler (client=client@entry=0x260a9f0, ignore_cancelled=0) at gdbusnamewatching.c:242 ignore_cancelled = 0 client = 0x260a9f0 #5 0x000000342b8cb978 in on_name_owner_changed (connection=<optimized out>, sender_name=0x7f04c46354d0 "org.freedesktop.DBus", object_path=<optimized out>, interface_name=0x7f04c44f16d0 "org.freedesktop.DBus", signal_name=<optimized out>, parameters=0x7f04c45ec610, user_data=0x260a9f0) at gdbusnamewatching.c:307 old_owner = 0x3902aa6 ":1.10" name = 0x3902aa0 ":1.10" new_owner = 0x3902aac "" connection = <optimized out> sender_name = 0x7f04c46354d0 "org.freedesktop.DBus" object_path = <optimized out> parameters = 0x7f04c45ec610 interface_name = 0x7f04c44f16d0 "org.freedesktop.DBus" signal_name = <optimized out> user_data = 0x260a9f0 client = 0x260a9f0 #6 0x000000342b8bc435 in emit_signal_instance_in_idle_cb (data=0x7f04c42edc50) at gdbusconnection.c:3743 signal_instance = 0x7f04c42edc50 parameters = 0x7f04c45ec610 has_subscription = 1 #7 0x0000003aaca492a6 in g_main_dispatch (context=0xeb6ac0) at gmain.c:3066 dispatch = 0x3aaca46150 <g_idle_dispatch> was_in_call = 0 user_data = 0x7f04c42edc50 callback = 0x342b8bc3c0 <emit_signal_instance_in_idle_cb> cb_funcs = 0x3aacd2a8e0 <g_source_callback_funcs> cb_data = 0x7f04c4635480 need_destroy = <optimized out> current_source_link = {data = 0x7f04c46353b0, next = 0x0} source = 0x7f04c46353b0 current = 0xecaa10 i = 10 #8 g_main_context_dispatch (context=context@entry=0xeb6ac0) at gmain.c:3642 No locals. #9 0x0000003aaca49628 in g_main_context_iterate (context=0xeb6ac0, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at gmain.c:3713 max_priority = 0 timeout = 0 some_ready = 1 nfds = <optimized out> allocated_nfds = 11 fds = 0x40e9ba0 #10 0x0000003aaca49a3a in g_main_loop_run (loop=0xebbbc0) at gmain.c:3907 __PRETTY_FUNCTION__ = "g_main_loop_run" #11 0x0000003dd5262ca8 in meta_run () at core/main.c:556 log_domains = {0x0, 0x3dd52ba001 "mutter", 0x3dd52b81a5 "Gtk", 0x3dd52b81a9 "Gdk", 0x3dd52b81ad "GLib", 0x3dd52b81b2 "Pango", 0x3dd52b81b8 "GLib-GObject", 0x3dd52b81c5 "GThread"} i = <optimized out> #12 0x0000000000402131 in main (argc=1, argv=0x7fff091c2a28) at main.c:439 ctx = <optimized out> error = 0x0 ecode = <optimized out> sender = 0x7f04c4009ab0
I have exactly the same backtrace several times per day. Not related to plymouth however, but to gdm. There are several accounts on this computer, and regularly when someone tries to log in, he gets a black screen, with gdm using 100% CPU, blocked on ghash.c:552 This is quite annoying. gdm 3.10.0.1-1.fc20 glib2 2.38.2-2.fc20
This message is a notice that Fedora 19 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 19. It is Fedora's policy to close all bug reports from releases that are no longer maintained. Approximately 4 (four) weeks from now this bug will be closed as EOL if it remains open with a Fedora 'version' of '19'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 19 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 19 changed to end-of-life (EOL) status on 2015-01-06. Fedora 19 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.