Bug 66960 - SIGSEGV from "ld-linux.so.2 libpthread.so.0"
SIGSEGV from "ld-linux.so.2 libpthread.so.0"
Status: CLOSED NOTABUG
Product: Red Hat Linux
Classification: Retired
Component: glibc (Show other bugs)
7.3
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Jakub Jelinek
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2002-06-19 01:22 EDT by John Reiser
Modified: 2016-11-24 10:14 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2002-06-19 10:59:05 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description John Reiser 2002-06-19 01:22:27 EDT
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:
Comment 1 Jakub Jelinek 2002-06-19 10:36:48 EDT
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.
Comment 2 John Reiser 2002-06-19 10:58:59 EDT
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].
Comment 3 Jakub Jelinek 2002-06-19 11:10:38 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.