Bug 1130633

Summary: [abrt] systemd: crash.lto_priv(): systemd killed by SIGSEGV
Product: [Fedora] Fedora Reporter: Lukas Slebodnik <lslebodn>
Component: systemdAssignee: systemd-maint
Status: CLOSED DUPLICATE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 20CC: cks-rhbugzilla, johannbg, lnykryn, lslebodn, msekleta, s, systemd-maint, vpavlin, zbyszek
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Unspecified   
URL: https://retrace.fedoraproject.org/faf/reports/bthash/871852a2062812365e03c623b8e80b7816954d18
Whiteboard: abrt_hash:575d172aab77ba016e0ebe994d2444c22914cff6
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2014-12-12 20:06:19 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
File: backtrace
none
File: cgroup
none
File: core_backtrace
none
File: dso_list
none
File: limits
none
File: maps
none
File: open_fds
none
File: proc_pid_status
none
File: var_log_messages none

Description Lukas Slebodnik 2014-08-15 17:55:31 UTC
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

Comment 1 Lukas Slebodnik 2014-08-15 17:55:35 UTC
Created attachment 927203 [details]
File: backtrace

Comment 2 Lukas Slebodnik 2014-08-15 17:55:36 UTC
Created attachment 927204 [details]
File: cgroup

Comment 3 Lukas Slebodnik 2014-08-15 17:55:38 UTC
Created attachment 927205 [details]
File: core_backtrace

Comment 4 Lukas Slebodnik 2014-08-15 17:55:39 UTC
Created attachment 927206 [details]
File: dso_list

Comment 5 Lukas Slebodnik 2014-08-15 17:55:40 UTC
Created attachment 927207 [details]
File: limits

Comment 6 Lukas Slebodnik 2014-08-15 17:55:42 UTC
Created attachment 927208 [details]
File: maps

Comment 7 Lukas Slebodnik 2014-08-15 17:55:43 UTC
Created attachment 927209 [details]
File: open_fds

Comment 8 Lukas Slebodnik 2014-08-15 17:55:44 UTC
Created attachment 927210 [details]
File: proc_pid_status

Comment 9 Lukas Slebodnik 2014-08-15 17:55:46 UTC
Created attachment 927211 [details]
File: var_log_messages

Comment 10 Zbigniew Jędrzejewski-Szmek 2014-09-01 18:38:27 UTC
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.

Comment 11 Zbigniew Jędrzejewski-Szmek 2014-09-01 18:46:00 UTC
This doesn't seem right... signal_agent_released was added in systemd 209.

Comment 12 Lukas Slebodnik 2014-09-02 07:59:00 UTC
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?

Comment 13 Zbigniew Jędrzejewski-Szmek 2014-09-02 12:17:27 UTC
I don't think I can generate the backtrace without the core file. If you know how, please explain.

Comment 14 Lukas Slebodnik 2014-09-02 12:29:50 UTC
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

Comment 15 Lukas Slebodnik 2014-09-02 12:34:57 UTC
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/

Comment 16 Chris Siebenmann 2014-12-12 19:34:56 UTC
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.)

Comment 17 Lukas Slebodnik 2014-12-12 20:06:19 UTC

*** This bug has been marked as a duplicate of bug 1167044 ***