This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug dynamic-link/20107] New: LD segfault during relocation while processing non-lazy libraries
- From: "sourceware-bugzilla at zulan dot net" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sourceware dot org
- Date: Tue, 17 May 2016 07:45:28 +0000
- Subject: [Bug dynamic-link/20107] New: LD segfault during relocation while processing non-lazy libraries
- Auto-submitted: auto-generated
https://sourceware.org/bugzilla/show_bug.cgi?id=20107
Bug ID: 20107
Summary: LD segfault during relocation while processing
non-lazy libraries
Product: glibc
Version: 2.23
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: dynamic-link
Assignee: unassigned at sourceware dot org
Reporter: sourceware-bugzilla at zulan dot net
Target Milestone: ---
Created attachment 9265
--> https://sourceware.org/bugzilla/attachment.cgi?id=9265&action=edit
minimal example to reproduce (part 1/4)
I ran across a segfault in ld-linux when used with the latest Intel compiler
16.03. I was able to reproduce this with a minimal example using the following
setup:
A statically linked shared library with -z now "libcore.so", that uses glibc
symbols (e.g. memmove)
A shared library "libuser.so" linked against said library.
A binary linked against -luser.
When the loader processes libcore.so (first, and in non-lazy fasion), it
segfaults during relocation of "memmove". It appears some internal structure is
not yet initialized:
57406: relocation processing: ./libcore.so
57406: symbol=memmove; lookup in file=...test/ldseg/clean/a.out [0]
57406: symbol=memmove; lookup in file=./libuser.so [0]
57406: symbol=memmove; lookup in
file=...glibc/install/head-debug/lib/libc.so.6 [0]
57406: binding file ./libcore.so [0] to
...glibc/install/head-debug/lib/libc.so.6 [0]: normal symbol `memmove'
Program received signal SIGSEGV, Segmentation fault.
0x00002aaaaaf4e851 in ?? ()
(gdb) bt
#0 0x00002aaaaaf4e851 in ?? ()
#1 0x00002aaaaaab6b8d in elf_machine_rela (skip_ifunc=0,
reloc_addr_arg=0x2aaaab45f500, version=0x0, sym=<optimized out>,
reloc=0x2aaaab25f2b0, map=0x2aaaaaad2958) at ../sysdeps/x86_64/dl-machine.h:315
#2 elf_dynamic_do_Rela (skip_ifunc=0, lazy=0, nrelative=0, relsize=96,
reladdr=46912504197808, map=0x2aaaaaad2958) at do-rel.h:170
#3 _dl_relocate_object (scope=0x2aaaaaad2cb0, reloc_mode=<optimized out>,
consider_profiling=consider_profiling@entry=0) at dl-reloc.c:258
#4 0x00002aaaaaaaf316 in dl_main (phdr=<optimized out>, phnum=<optimized out>,
user_entry=<optimized out>, auxv=<optimized out>) at rtld.c:2070
#5 0x00002aaaaaac141d in _dl_sysdep_start
(start_argptr=start_argptr@entry=0x7fffffffe4b0,
dl_main=dl_main@entry=0x2aaaaaaaccb1 <dl_main>) at ../elf/dl-sysdep.c:249
#6 0x00002aaaaaaafa92 in _dl_start_final (arg=0x7fffffffe4b0) at rtld.c:307
#7 _dl_start (arg=0x7fffffffe4b0) at rtld.c:413
#8 0x00002aaaaaaabac8 in _start () from
...glibc/install/head-debug/lib/ld-linux-x86-64.so.2
#9 0x0000000000000001 in ?? ()
#10 0x00007fffffffe749 in ?? ()
#11 0x0000000000000000 in ?? ()
The contents of "sym" are:
$2 = {st_name = 32, st_info = 16 '\020', st_other = 0 '\000', st_shndx = 0,
st_value = 0, st_size = 0}
Without knowing details, it seems to me that st_value is not initialized and
the code jumps to the very beginning of glibc.so.
--
You are receiving this mail because:
You are on the CC list for the bug.