Bug 1074323

Summary: [abrt] coreutils: __libc_csu_init(): ls killed by SIGSEGV
Product: [Fedora] Fedora Reporter: grisetti <jgrisetti>
Component: glibcAssignee: Carlos O'Donell <codonell>
Status: CLOSED WORKSFORME QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 20CC: admiller, codonell, fweimer, jakub, kdudka, kzak, law, ooprala, ovasik, p, pfrankli, spoyarek, twaugh
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Unspecified   
URL: https://retrace.fedoraproject.org/faf/reports/bthash/3aa2711621d8034b33c93408eafd26978e714b3b
Whiteboard: abrt_hash:ac4d780e8ec0fd3df11d13e88aeebfdf4203c9cc
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2014-06-20 02:26:53 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: environ
none
File: exploitable
none
File: limits
none
File: maps
none
File: open_fds
none
File: proc_pid_status
none
File: var_log_messages none

Description grisetti 2014-03-09 19:44:09 UTC 
Version-Release number of selected component:
coreutils-8.21-20.fc20

Additional info:
reporter:       libreport-2.1.12
backtrace_rating: 4
cmdline:        ls /etc/bash_completion.d
crash_function: __libc_csu_init
executable:     /usr/bin/ls
kernel:         3.13.5-202.fc20.x86_64
runlevel:       N 5
type:           CCpp
uid:            1000

Truncated backtrace:
Thread no. 1 (2 frames)
 #0 __libc_csu_init
 #2 _start
Comment 1 grisetti 2014-03-09 19:44:13 UTC 
Created attachment 872454 [details]
File: backtrace
Comment 2 grisetti 2014-03-09 19:44:14 UTC 
Created attachment 872455 [details]
File: cgroup
Comment 3 grisetti 2014-03-09 19:44:16 UTC 
Created attachment 872456 [details]
File: core_backtrace
Comment 4 grisetti 2014-03-09 19:44:17 UTC 
Created attachment 872457 [details]
File: dso_list
Comment 5 grisetti 2014-03-09 19:44:19 UTC 
Created attachment 872458 [details]
File: environ
Comment 6 grisetti 2014-03-09 19:44:21 UTC 
Created attachment 872459 [details]
File: exploitable
Comment 7 grisetti 2014-03-09 19:44:22 UTC 
Created attachment 872460 [details]
File: limits
Comment 8 grisetti 2014-03-09 19:44:24 UTC 
Created attachment 872461 [details]
File: maps
Comment 9 grisetti 2014-03-09 19:44:26 UTC 
Created attachment 872462 [details]
File: open_fds
Comment 10 grisetti 2014-03-09 19:44:27 UTC 
Created attachment 872463 [details]
File: proc_pid_status
Comment 11 grisetti 2014-03-09 19:44:29 UTC 
Created attachment 872464 [details]
File: var_log_messages
Comment 12 Ondrej Vasik 2014-06-19 21:25:33 UTC 
Moving to glibc, as the crash has nothing to do with ls itself. However - I think there is not enough data to further analyze the problem. Is the issue reproducible? Something special in your setup?
Comment 13 Carlos O'Donell 2014-06-20 02:26:53 UTC 
The crash happens while attempting to execute the applications initializer function. The crash isn't *in* the initializer, but in the code leading up to the call. The only thing that needs to be done leading up to the call is to setup the arguments which include argc, argv, environ, and auxvec. The only way these get corrupted is by the kernel or bad hardware. There is no way we would crash here otherwise.

Closing since it works for me and I can't reproduce.