Description of problem: upgrade from fedora 20 to fedora 21 Version-Release number of selected component: systemd-208-21.fc20 Additional info: reporter: libreport-2.2.3 backtrace_rating: 4 cmdline: /usr/lib/systemd/systemd --system --deserialize 19 crash_function: crash.lto_priv executable: /usr/lib/systemd/systemd kernel: 3.15.8-200.fc20.x86_64 runlevel: N 5 type: CCpp uid: 0 Truncated backtrace: Thread no. 1 (10 frames) #1 crash.lto_priv #3 join_path #4 cg_enumerate_processes.constprop #5 cg_is_empty_recursive.constprop #6 signal_agent_released #7 bus_match_run #18 process_match.lto_priv #19 bus_process_internal.constprop #20 io_callback #21 source_dispatch.lto_priv
Created attachment 927203 [details] File: backtrace
Created attachment 927204 [details] File: cgroup
Created attachment 927205 [details] File: core_backtrace
Created attachment 927206 [details] File: dso_list
Created attachment 927207 [details] File: limits
Created attachment 927208 [details] File: maps
Created attachment 927209 [details] File: open_fds
Created attachment 927210 [details] File: proc_pid_status
Created attachment 927211 [details] File: var_log_messages
Any chance you could install matching systemd-debuginfo.rpm and redo the gdb backtrace? Currently systemd.rpm and systemd-debuginfo.rpm versions don't match so the backtrace is nearly useless.
This doesn't seem right... signal_agent_released was added in systemd 209.
As I already wrote in description of problem. I was upgrading my fedora 20 to 21. I checked log files from upgrade and problem can be in these versions: systemd-208-21.fc20.x86_64 systemd-215-11.fc21.x86_64 I have already removed abrt reports. I think you can download systemd-debuginfo*.rpm yourself from koji and generate backtrace. I provided exact versions of packages. BTW: I sent report after rebooting machine. It was from fedora 21, but it happened on fedora 20. The problem is it can happen to anyone who will try to upgrade from f20 -> f21. Do you need any other info from me?
I don't think I can generate the backtrace without the core file. If you know how, please explain.
I thought that coredump is uploaded, this was a reason why I removed abrt reports. My fault. You can close this bug due to insufficient data. BTW I did the same mistake in BZ1130631
Or you can try to analyse report from retrace[1], but I know that coredump would be much more helpful, because from backtrace you cannot see value of local variables ... [1] https://retrace.fedoraproject.org/faf/reports/420377/
This looks like it may be the same issue as BZ1167044. The stack traces look the same and the situations are similar-to-identical. (Spotted by userbinator on Hacker News, I'm just putting in a comment to link the two bug reports since I'm a (very) interested bystander.)
*** This bug has been marked as a duplicate of bug 1167044 ***