Bug 91141 - telnet segfaults with LD_LIBRARY_PATH=.
telnet segfaults with LD_LIBRARY_PATH=.
Status: CLOSED CURRENTRELEASE
Product: Red Hat Linux
Classification: Retired
Component: glibc (Show other bugs)
9
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Jakub Jelinek
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2003-05-19 08:16 EDT by Pádraig Brady
Modified: 2016-11-24 10:15 EST (History)
2 users (show)

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


Attachments (Terms of Use)
strace diff (2.31 KB, application/octet-stream)
2003-05-19 09:41 EDT, Pádraig Brady
no flags Details

  None (edit)
Description Pádraig Brady 2003-05-19 08:16:22 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3b) Gecko/20030210

Description of problem:
if LD_LIBRARY_PATH=. and (host=localhost or host=127.0.0.1):
    telnet segfaults

These crash it:

LD_LIBRARY_PATH=. telnet localhost 6000
LD_LIBRARY_PATH=. telnet 127.0.0.1 6000

This doesn't:

LD_LIBRARY_PATH=. telnet `hostname` 6000


Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
1.LD_LIBRARY_PATH=. telnet 127.0.0.1 6000
    

Actual Results:  telnet segfaults

Additional info:
Comment 1 Harald Hoyer 2003-05-19 08:58:20 EDT
$ LD_LIBRARY_PATH=. telnet 127.0.0.1 6000
Trying 127.0.0.1...
Connected to localhost.localdomain (127.0.0.1).
Escape character is '^]'.
^]

telnet> quit
Connection closed.
Comment 2 Harald Hoyer 2003-05-19 09:00:12 EDT
You might sent the infos printed by:
$ LD_DEBUG=files LD_LIBRARY_PATH=. telnet 127.0.0.1 6000
Comment 3 Pádraig Brady 2003-05-19 09:09:02 EDT
It happens on 2 different rh9 installations here.
rh9 beta on my laptop doesn't have the problem.
Interestingly adding LD_DEBUG=files causes the problem to "go away"!
output from LD_DEBUG follows:

file=libutil.so.1;  needed by telnet
file=libutil.so.1;  generating link map
  dynamic: 0x4002f998  base: 0x4002d000   size: 0x00002b28
    entry: 0x4002de20  phdr: 0x4002d034  phnum:          6


file=libncurses.so.5;  needed by telnet
file=libncurses.so.5;  generating link map
  dynamic: 0x4006daa0  base: 0x40030000   size: 0x0003e84c
    entry: 0x4003e1c0  phdr: 0x40030034  phnum:          3


file=libc.so.6;  needed by telnet
file=libc.so.6;  generating link map
  dynamic: 0x42130920  base: 0x00000000   size: 0x00132f08
    entry: 0x42015660  phdr: 0x42000034  phnum:          8


calling init: /lib/tls/libc.so.6


calling init: /usr/lib/libncurses.so.5


calling init: /lib/libutil.so.1


initialize program: telnet


transferring control: telnet

file=libnss_files.so.2;  generating link map
  dynamic: 0x4007b434  base: 0x40070000   size: 0x0000b7dc
    entry: 0x40071d10  phdr: 0x40070034  phnum:          6


calling init: /lib/libnss_files.so.2

opening file=/lib/libnss_files.so.2; opencount == 1
Comment 4 Harald Hoyer 2003-05-19 09:12:28 EDT
why do you need LD_LIBRARY_PATH=. anyway?
Comment 5 Pádraig Brady 2003-05-19 09:41:35 EDT
Created attachment 91788 [details]
strace diff

crashing version on left
Comment 6 Pádraig Brady 2003-05-19 09:43:23 EDT
That LD_LIBRARY_PATH was just a trigger. One of the developers
noticed it here with other LD_LIBRARY_PATHS. Trying out other
LD_LIBRARY_PATHS shows:

no crash for:

  /
  /lib
  anything/a
  /anything

crash for:

  /usr
  /usr/lib
  anything

Hmm the crashing version (according to strace) does
also interact with /var/run/.nscd_socket for some reason?
sdiff of straces above
Comment 7 Harald Hoyer 2003-05-19 09:58:30 EDT
seems like this is more likely a loader bug in glibc, reassigning
Comment 8 Ulrich Drepper 2003-10-02 01:47:57 EDT
Repeat after bugzilla reload:

This is not a bug.  The symbols _init and _fini like all symbols starting with _
(with a few documented exceptions) are reserved.  The correct way to do what you
want is to use the mechanism clearly documented in the gcc manual, namely using
the constructor and destructor function attributes.  No bug.
Comment 9 Ulrich Drepper 2003-10-02 04:40:45 EDT
Comment made for the wrong bug.  Reopen.  Curse this disk error.
Comment 10 Ulrich Drepper 2003-10-27 03:45:10 EST
We did fix a problem recently which might be responsible for this crash.  If you
can install and run Fedora Core, give the current glibc-2.3.2-99 a try.  I
expect that the change will also be in an glibc errate for RHL9 when there is
one, but this doesn't exist yet.
Comment 11 Pádraig Brady 2003-10-28 05:17:06 EST
I could reproduce the problem on redhat 9 with glibc-2.3.2-27.9

I just installed fedora which had glibc-2.3.2-98
and I couldn't reproduce the problem.

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