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
Created attachment 872454 [details] File: backtrace
Created attachment 872455 [details] File: cgroup
Created attachment 872456 [details] File: core_backtrace
Created attachment 872457 [details] File: dso_list
Created attachment 872458 [details] File: environ
Created attachment 872459 [details] File: exploitable
Created attachment 872460 [details] File: limits
Created attachment 872461 [details] File: maps
Created attachment 872462 [details] File: open_fds
Created attachment 872463 [details] File: proc_pid_status
Created attachment 872464 [details] File: var_log_messages
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?
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.