Bug 91141

Summary: telnet segfaults with LD_LIBRARY_PATH=.
Product: [Retired] Red Hat Linux Reporter: Pádraig Brady <p>
Component: glibcAssignee: Jakub Jelinek <jakub>
Status: CLOSED CURRENTRELEASE QA Contact: Brian Brock <bbrock>
Severity: medium Docs Contact:
Priority: medium    
Version: 9CC: fweimer, harald
Target Milestone: ---   
Target Release: ---   
Hardware: i686   
OS: Linux   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2003-10-28 10:17:06 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Description Flags
strace diff none

Description Pádraig Brady 2003-05-19 12:16:22 UTC
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=
    telnet segfaults

These crash it:

LD_LIBRARY_PATH=. telnet localhost 6000
LD_LIBRARY_PATH=. telnet 6000

This doesn't:

LD_LIBRARY_PATH=. telnet `hostname` 6000

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

How reproducible:

Steps to Reproduce:
1.LD_LIBRARY_PATH=. telnet 6000

Actual Results:  telnet segfaults

Additional info:

Comment 1 Harald Hoyer 2003-05-19 12:58:20 UTC
$ LD_LIBRARY_PATH=. telnet 6000
Connected to localhost.localdomain (
Escape character is '^]'.

telnet> quit
Connection closed.

Comment 2 Harald Hoyer 2003-05-19 13:00:12 UTC
You might sent the infos printed by:
$ LD_DEBUG=files LD_LIBRARY_PATH=. telnet 6000

Comment 3 Pádraig Brady 2003-05-19 13:09:02 UTC
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 13:12:28 UTC
why do you need LD_LIBRARY_PATH=. anyway?

Comment 5 Pádraig Brady 2003-05-19 13:41:35 UTC
Created attachment 91788 [details]
strace diff

crashing version on left

Comment 6 Pádraig Brady 2003-05-19 13:43:23 UTC
That LD_LIBRARY_PATH was just a trigger. One of the developers
noticed it here with other LD_LIBRARY_PATHS. Trying out other

no crash for:


crash for:


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 13:58:30 UTC
seems like this is more likely a loader bug in glibc, reassigning

Comment 8 Ulrich Drepper 2003-10-02 05:47:57 UTC
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 08:40:45 UTC
Comment made for the wrong bug.  Reopen.  Curse this disk error.

Comment 10 Ulrich Drepper 2003-10-27 08:45:10 UTC
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 10:17:06 UTC
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.