Bug 980674

Summary: [abrt] glibc-2.17-11.fc19: elf_machine_rela: Process /usr/lib64/ld-2.17.so was killed by signal 11 (SIGSEGV)
Product: [Fedora] Fedora Reporter: mdmpsyd <mdmpsyd>
Component: glibcAssignee: Carlos O'Donell <codonell>
Status: CLOSED NOTABUG QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 19CC: antking, codonell, fweimer, jakub, law, mdmpsyd, pfrankli, schwab, spoyarek
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Unspecified   
Whiteboard: abrt_hash:6f2b6bd9a887e478dfc60dfb0a878e8d8e079db2
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-10-18 14:59:41 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: limits
none
File: maps
none
File: open_fds
none
File: proc_pid_status
none
File: var_log_messages none

Description mdmpsyd@gmail.com 2013-07-03 02:37:32 UTC 
Version-Release number of selected component:
glibc-2.17-11.fc19

Additional info:
reporter:       libreport-2.1.5
backtrace_rating: 4
cmdline:        /lib64/ld-linux-x86-64.so.2 /usr/lib64/libcairo.so.2.11200.14
crash_function: elf_machine_rela
executable:     /usr/lib64/ld-2.17.so
kernel:         3.9.8-300.fc19.x86_64
runlevel:       N 5
uid:            0

Truncated backtrace:
Thread no. 1 (8 frames)
 #0 elf_machine_rela at ../sysdeps/x86_64/dl-machine.h:395
 #1 elf_dynamic_do_Rela at do-rel.h:137
 #2 _dl_relocate_object at dl-reloc.c:295
 #3 _dl_receive_error at dl-error.c:209
 #4 dl_main at rtld.c:1959
 #5 _dl_sysdep_start at ../elf/dl-sysdep.c:241
 #6 _dl_start_final at rtld.c:329
 #7 _dl_start at rtld.c:555

Potential duplicate: bug 922446
Comment 1 mdmpsyd@gmail.com 2013-07-03 02:37:37 UTC 
Created attachment 768024 [details]
File: backtrace
Comment 2 mdmpsyd@gmail.com 2013-07-03 02:37:41 UTC 
Created attachment 768025 [details]
File: cgroup
Comment 3 mdmpsyd@gmail.com 2013-07-03 02:37:45 UTC 
Created attachment 768026 [details]
File: core_backtrace
Comment 4 mdmpsyd@gmail.com 2013-07-03 02:37:50 UTC 
Created attachment 768027 [details]
File: dso_list
Comment 5 mdmpsyd@gmail.com 2013-07-03 02:37:55 UTC 
Created attachment 768028 [details]
File: environ
Comment 6 mdmpsyd@gmail.com 2013-07-03 02:37:59 UTC 
Created attachment 768029 [details]
File: limits
Comment 7 mdmpsyd@gmail.com 2013-07-03 02:38:04 UTC 
Created attachment 768030 [details]
File: maps
Comment 8 mdmpsyd@gmail.com 2013-07-03 02:38:08 UTC 
Created attachment 768031 [details]
File: open_fds
Comment 9 mdmpsyd@gmail.com 2013-07-03 02:38:12 UTC 
Created attachment 768032 [details]
File: proc_pid_status
Comment 10 mdmpsyd@gmail.com 2013-07-03 02:38:16 UTC 
Created attachment 768033 [details]
File: var_log_messages
Comment 11 Carlos O'Donell 2013-07-12 00:14:49 UTC 
The crash is while updating an R_X86_64_64 relocation. We shouldn't crash if the relocations are valid. The most likely case is that the program stomped all over the stack and this crash is a result of a corrupted stack.

Is this reproducible?
Comment 12 antking 2013-10-18 13:06:30 UTC 
Folks, I think this turned out to be a false alarm, at least my bug report. A change of RAM seemed to have cleared all the numerous problems I was experiencing with Fedora 19 on my new system build.

Apologies for the false alarm, and thanks for all the work you debuggers put in for the rest of us.

A. King
Comment 13 Carlos O'Donell 2013-10-18 14:59:41 UTC 
Thanks for confirming that this was a hardware issue. We've seen a lot of these problems in elf_machine_rela but we almost always track them down to program corruption. I'm marking this CLOSED/NOTABUG, please file a new issue if you run into this again.