Red Hat Bugzilla – Bug 66960
SIGSEGV from "ld-linux.so.2 libpthread.so.0"
Last modified: 2016-11-24 10:14:01 EST
From Bugzilla Helper: User-Agent: Mozilla/4.77 [en] (X11; U; Linux 2.2.19-6.2.16-KRUD-perfctr2.3.6 i586) Description of problem: /lib/ld-linux.so.2 can be used to invoke a main program, or also /lib/libc.so.6. But if used to invoke almost any other dynamic shared object, then you get a SIGSEGV, and the traceback varies with the pathname of the argument, and sometimes points inside ld-linux.so.2. Version-Release number of selected component (if applicable): glibc-2.2.5-34 How reproducible: Always Steps to Reproduce: 1. cd /lib; /lib/ld-linux.so.2 libpthread.so.0 2. cd /tmp; /lib/ld-linux.so.2 /lib/libpthread.so.0 3. Actual Results: Running under gdb: $ cd /lib $ gdb /lib/ld-linux.so.2 GNU gdb Red Hat Linux (5.1.90CVS-5) . . . (no debugging symbols found)... (gdb) run libpthread.so.0 Starting program: /lib/ld-2.2.5.so libpthread.so.0 Program received signal SIGSEGV, Segmentation fault. 0x8000601d in _dl_map_object_internal () (gdb) bt #0 0x8000601d in _dl_map_object_internal () #1 0x80002857 in dl_main () #2 0x8000dadb in _dl_sysdep_start () #3 0x80000f9f in _dl_start_final () #4 0x80000e1f in _dl_start () (gdb) inf reg eax 0x4000c242 1073791554 ecx 0x3 3 edx 0x0 0 ebx 0x800134c0 -2147404608 esp 0xbfffef10 0xbfffef10 ebp 0xbffff378 0xbffff378 esi 0xbffffb9d -1073742947 edi 0x0 0 eip 0x8000601d 0x8000601d eflags 0x10246 66118 cs 0x23 35 ss 0x2b 43 ds 0x2b 43 es 0x2b 43 fs 0x0 0 gs 0x0 0 (gdb) x/4i $pc 0x8000601d <_dl_map_object_internal+973>: testb $0x8,0x1e9(%edi) 0x80006024 <_dl_map_object_internal+980>: jne 0x800060c7 <_dl_map_object_internal+1143> 0x8000602a <_dl_map_object_internal+986>: mov 0xfffffbb8(%ebp),%edx 0x80006030 <_dl_map_object_internal+992>: test %edx,%edx (gdb) q Second case: $ cd /tmp $ gdb /lib/ld-linux.so.2 GNU gdb Red Hat Linux (5.1.90CVS-5) . . . (no debugging symbols found)... (gdb) run /lib/libpthread.so.0 Starting program: /lib/ld-2.2.5.so /lib/libpthread.so.0 Program received signal SIGSEGV, Segmentation fault. 0x00000001 in ?? () (gdb) bt #0 0x00000001 in ?? () Cannot access memory at address 0x0 (gdb) inf reg eax 0x2f2a988c 791320716 ecx 0x400120a0 1073815712 edx 0xafa 2810 ebx 0x800134c0 -2147404608 esp 0xbffffa88 0xbffffa88 ebp 0x0 0x0 esi 0xbffffa90 -1073743216 edi 0x400043a0 1073759136 eip 0x1 0x1 eflags 0x10216 66070 cs 0x23 35 ss 0x2b 43 ds 0x2b 43 es 0x2b 43 fs 0x0 0 gs 0x0 0 Expected Results: NoSIGSEGV. Probably a message about no entry point (or entry point not within loaded range), followed by exit with non-zero status. Additional info:
Um, why? You don't get SIGSEGV when running kernel image or some other garbage? The libraries have entry point set by default to the start of .text section, so whatever is there is run. Both ld.so and libc.so make sure the entry point runs something useful, but why should every single library care about this? LD_TRACE_LOADED_OBJECTS=1 /lib/ld-linux.so.2 libpthread.so.0 should work, /lib/ld-linux.so.2 libpthread.so.0 has undefined behaviour.
Please reconsider. The suggested command still gives SIGSEGV: $ cd /lib; LD_TRACE_LOADED_OBJECTS=1 /lib/ld-linux.so.2 libpthread.so.0 Segmentation fault $ Also, the gdb traceback in case 1 (where there is no "/lib" on the first argument "libpthread.so.0") shows SIGSEGV happens _inside_ ld-linux.so.2, before transfering control to the loaded object. Register %edi is 0; it's a null-pointer bug in _dl_map_object_internal+973 [or earlier].
It is actually LD_TRACE_LOADED_OBJECTS=1 /lib/ld-linux.so.2 ./libpthread.so.0 or LD_TRACE_LOADED_OBJECTS=1 /lib/ld-linux.so.2 /lib/libpthread.so.0 which is supposed to work and /usr/bin/ldd takes care of adding ./ if there are no slashes in the filename, so I don't see any need for reconsidering this. LD_TRACE_LOADED_OBJECTS=1 is glibc internal thing, users should use ldd.