Bug 144749 - bash should be linked against external libreadline
bash should be linked against external libreadline
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: bash (Show other bugs)
rawhide
All Linux
low Severity low
: ---
: ---
Assigned To: Roman Rakus
Fedora Extras Quality Assurance
bzcl34nup
: Reopened
Depends On: 253431
Blocks:
  Show dependency treegraph
 
Reported: 2005-01-10 22:59 EST by John Smith
Modified: 2014-01-12 19:06 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-05-21 11:02:01 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
shared readline build; nothing interesting here. (1005 bytes, patch)
2007-08-19 08:05 EDT, Jan Kratochvil
no flags Details | Diff
time(1) with a better precision. (1.05 KB, text/plain)
2007-08-20 14:11 EDT, Jan Kratochvil
no flags Details

  None (edit)
Description John Smith 2005-01-10 22:59:09 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5)
Gecko/20041111 Firefox/1.0

Description of problem:
The 'bash' executable shipped with FC3 uses its
internal readline.  As a consequence, it uses
the termcap database and it ignores the terminfo
database.  This is a bug: no program should only
rely on termcap.

To fix this problem, it suffices to link bash
against the external readline library (with the
--with-installed-readline configure option).
Note that bash doesn't want to link against
a libreadline older than 5.0; the libreadline
shipped with FC3 is 4.3, so it should be upgraded
first.

Example of real-life problem caused by this bug:
in a rxvt-unicode with the default installation
options, the "Ctrl-l" key combination doesn't work
as expected if you're running bash.  Note that it
works fine with zsh, which relies on terminfo rather
than termcap.

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


How reproducible:
Always

Steps to Reproduce:
n/a
    

Additional info:
Comment 1 Tim Waugh 2005-01-12 06:43:15 EST
You need bash to install readline, since that's how RPM scriptlets are run.
Comment 2 Jan Kratochvil 2007-08-19 08:05:54 EDT
Created attachment 161819 [details]
shared readline build; nothing interesting here.
Comment 3 Jan Kratochvil 2007-08-19 08:15:31 EDT
Bug 253431 should implement readline without the `/bin/sh' dependency.
I hope bash would get rebuilt with the shared readline afterwards.
Comment 4 Miroslav Lichvar 2007-08-20 13:13:45 EDT
The fix for bug #253431 will be pretty easy if bash is really going to use the
system readline. An entry for readline will be added to info/dir file in the
info package so post and preun scripts in readline package don't need to call
install-info. Also, the library will have to be moved to /lib.

However, there are performance reasons to not use the system readline. IIRC, the
library has many relocations (impossible to fix without breaking API) and causes
noticeable slowdown.
Comment 5 Jan Kratochvil 2007-08-20 14:11:00 EDT
Created attachment 161911 [details]
time(1) with a better precision.

The problem is not due to the relocations.  Relocations could be reduced by
wrapping some of the libreadline function references into a wrapper:

static int local_rl_newline (int a, int b) { return rl_newline (a, b); }
cmap[x].function = rl_newline;
-> change to ->
cmap[x].function = local_rl_newline;

Still the slowdown is due to the general kernel overhead of loading another
shared object:
 
 runtime linker statistics:
-  total startup time in dynamic loader: 593808 clock cycles
-	     time needed for relocation: 21576 clock cycles (3.6%)
+  total startup time in dynamic loader: 919908 clock cycles
+	     time needed for relocation: 69444 clock cycles (7.5%)
		  number of relocations: 0
-      number of relocations from cache: 26
+      number of relocations from cache: 652
	 number of relative relocations: 0
-	    time needed to load objects: 391356 clock cycles (65.9%)
+	    time needed to load objects: 654432 clock cycles (71.1%)
 runtime linker statistics: 
	    final number of relocations: 15
-final number of relocations from cache: 26
+final number of relocations from cache: 652

Relocations cause those approx. 40000 clock cycles but still the 300000 clock
cycles are spent due to the kernel syscalls overhead for another 3 libraries
(libreadline + libhistory + libtinfo).


The overall end-to-end run stats:

prelinked static readline: 0.00271 sec
prelinked shared readline: 0.00294 sec

Tested on: bash -c 'exit'
with a complete fork()/execlp()/waitpid().

This is the worst ever slowdown which can happen and it is 8.487%.
As the user may notice only 0.2+ sec slowdown you would have to run empty bash
869+ times to make the user notice anything.  It would run 2.35 sec with the
original static-readline bash.

Sure many commands could be sped up a bit by static builds but we are the
Defining technology Company of the 21st Century. ;-)
Comment 6 Bug Zapper 2008-04-03 11:49:06 EDT
Based on the date this bug was created, it appears to have been reported
against rawhide during the development of a Fedora release that is no
longer maintained. In order to refocus our efforts as a project we are
flagging all of the open bugs for releases which are no longer
maintained. If this bug remains in NEEDINFO thirty (30) days from now,
we will automatically close it.

If you can reproduce this bug in a maintained Fedora version (7, 8, or
rawhide), please change this bug to the respective version and change
the status to ASSIGNED. (If you're unable to change the bug's version
or status, add a comment to the bug and someone will change it for you.)

Thanks for your help, and we apologize again that we haven't handled
these issues to this point.

The process we're following is outlined here:
http://fedoraproject.org/wiki/BugZappers/F9CleanUp

We will be following the process here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this
doesn't happen again.
Comment 7 Bug Zapper 2008-05-06 20:05:13 EDT
This bug has been in NEEDINFO for more than 30 days since feedback was
first requested. As a result we are closing it.

If you can reproduce this bug in the future against a maintained Fedora
version please feel free to reopen it against that version.

The process we're following is outlined here:
http://fedoraproject.org/wiki/BugZappers/F9CleanUp
Comment 8 Stepan Kasal 2008-05-20 12:33:01 EDT
Reopening.  Though current bash uses terminfo, not termcap I still think our
bash should use system readline.

Thanks to Jan's profiling in comment #5, we may rest assured that there is no
performance problem with that.
Comment 9 Stepan Kasal 2008-05-21 11:02:01 EDT
Jakub Jelinek has toldme this:
The radline API uses lots of global variables, which make linking against it to
expensive.  The impact on /bin/bash startup might not be neglectable.
Since bash is executed many times during startup and even when processing a more
complicated shell script, one would have to be very careful about performance
impact before dynamic link against readline.

This convinces me that the potential gain is not worth the price of the
investigation, so I'm undoing my yesterday reopen.

Please note that the original reason for the suggestion was that bash used
termcap back then, which is no longer true; it uses terminfo as all civilized
citizens of todays Fedora world.

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