Bug 61297 - [patch] readline: Bash core dump (shells/bash2)
Summary: [patch] readline: Bash core dump (shells/bash2)
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: Normal Affects Only Me
Assignee: Andrey A. Chernov
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2004-01-13 08:00 UTC by Brad Bender
Modified: 2004-07-22 06:41 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Brad Bender 2004-01-13 08:00:38 UTC
Fresh install of FreeBSD 5.2-RELEASE on a Dell Inspiron 5100 Laptop running XFree86 Version 4.3.0.  While in an xterm running 'bash version 2.05b.0(1)-release (i386-portbld-freebsd5.2)', pressing any of the F-keys ie. F1,F2,F3 etc. will get a bash core dump.  I have AGP disabled in the kernel which is probably playing a role.  Bash doesn't crash from the terminal if I do the same.  This bug doesn't affect /bin/sh under the same conditions.

Fix: 

Don't use Bash.  /bin/sh doesn't crash under the same conditions.
How-To-Repeat: Run an xterm in XFree86 4.3.0.  Run a bash shell if you havn't already.  Press any of the F-keys and you'll get a bash.core dump.

You may need to disable AGP in the kernel to reproduce this bug.
Comment 1 Mark Linimon freebsd_committer freebsd_triage 2004-01-13 15:04:29 UTC
Responsible Changed
From-To: freebsd-ports-bugs->obrien

Over to maintainer of shells/bash2. 

Please, in the future, consider wrapping lines at 70 characters.
Comment 2 Pav Lucistnik freebsd_committer 2004-01-13 19:34:29 UTC
I'm running xterm with bash on 5.2-CURRENT, pressing F-keys like crazy
but it don't crashes! I think this PR is bogus and should be closed.

-- 
Pav Lucistnik <pav@oook.cz>
              <pav@FreeBSD.org>
Comment 3 Tobias Eichert 2004-03-15 13:04:10 UTC
Hello,
I've got the same problem as described above (on 5.2.1-p1).
For example, when I run blackbox using xterm and try to ALT+F2 (that's my 
usual configuration for switching to workspace 2) while xterm is focussed 
bash segfaults - that happens when bbkeys (which handles shortcuts to pass 
them to the wm) is not running.
Another situation is when working with 'konsole' under KDE - if I press 
shift+return at the same time 'konsole' crashes and dmesg shows:
"pid 659 (bash), uid 1001: exited on signal 4" - the same goes for pressing
the F3 and F4 buttons.

My X keyboard layout is:

Section "InputDevice"
        Identifier      "Generic Keyboard"
        Driver          "keyboard"
        Option          "CoreKeyboard"
        Option          "XkbRules"      "xfree86"
        Option          "XkbModel"      "pc102"
        Option          "XkbLayout"     "de"
        Option          "XkbVariant"    "nodeadkeys"
        Option          "AutoRepeat"    "200 30"
EndSection

It's non-critical as I simply can switch to tcsh - but I guess this bug should 
be addressed. It happens with ACPI enabled/disabled - seems it doesn't 
matter.
My kernel config is almost a default one - except that I removed things like 
SCSI/RAID and added some SMB entries.
 
If you need further information please tell me so.
As far as I can tell bash is 100% stable when not running under X. 

The whole shebang happens on a Thinkpad T40p - just to let you know.

Best regards,
Tobias
Comment 4 Dan Langille 2004-03-17 03:55:03 UTC
I have similar problems with bash under FreeBSD 5.2.1 and in KDE's
Konsole.

Press F1 while in a bash shell in Konsole and you get:

laptpo# bash
[root@laptop:/home/dan] # <PRESS F1 here>Illegal instruction (core
dumped) laptop#

This does not happen at the console.  only Konsole.  Nor under any
other shell I tried (/bin/sh, /bin/csh, /bin/tcsh).

This is bash-2.05b.007

$ ldd /usr/local/bin/bash
ldd: /usr/local/bin/bash: not a dynamic executable

The situation is 100% reproducible here. And duplicated by others.  I have
since changed to a dynamic bash.  The problem remains.

This supplied by Andy Fawcett <andy@athame.co.uk> in reply to my message
on kde-freebsd@

###
$ gdb /usr/local/bin/bash bash.core
(blah)
(no debugging symbols found)...
Core was generated by `bash'.
Program terminated with signal 4, Illegal instruction.

(gdb) bt
#0  0x2810b9d5 in _rl_dispatch_subseq () from /lib/libreadline.so.4
#1  0x2810b9be in _rl_dispatch () from /lib/libreadline.so.4
#2  0x2810bc28 in _rl_dispatch_subseq () from /lib/libreadline.so.4
#3  0x2810b9be in _rl_dispatch () from /lib/libreadline.so.4

and so on, for 2000+ lines (I stopped checking)

I'd call it a bash/readline problem, but I'm no expert
###


-- 
Dan Langille - BSDCan: http://www.bsdcan.org/
Comment 5 Allan Fields 2004-03-17 11:41:29 UTC
This appears to be a known issue under Linux as well and a patch
for readline is available:

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=98229

The patch that should fix the issue is listed below:
> Readline-Release: 4.3
> Patch-ID: readline43-001
> 
> Bug-Reported-by:   Thierry Vignaud <tvignaud@mandrakesoft.com>
> Bug-Reference-ID:  <m2wurdqvo0.fsf@vador.mandrakesoft.com> (bug-readline)
> Bug-Reference-URL:
> 
> Bug-Description:
> 
> Pressing certain key sequences causes an infinite loop in _rl_dispatch_subseq
> with the `key' argument set to 256.  This eventually causes bash to exceed
> the stack size limit and crash with a segmentation violation.
> 
> Patch:
> *** ../readline-4.3/bind.c      Thu Jan 24 11:15:52 2002
> --- bind.c      Wed Jul 31 09:11:18 2002
> ***************
> *** 312,316 ****
>              and the function bound  to `a' to be executed when the user
>              types `abx', leaving `bx' in the input queue. */
> !         if (k.function /* && k.type == ISFUNC */)
>             { 
>               map[ANYOTHERKEY] = k;
> --- 312,316 ----
>              and the function bound  to `a' to be executed when the user
>              types `abx', leaving `bx' in the input queue. */
> !         if (k.function && ((k.type == ISFUNC && k.function != rl_do_lowercase_version) || k.type == ISMACR))
>             { 
>               map[ANYOTHERKEY] = k;

Note also that there is a version of readline included with
bash and the system readline version under /usr/src/contrib/libreadline
that the port uses.

There is a patch on the GNU mirrors for bash-2.05b with the same fix
that the port should apply.

Ultimately this bug might be best directed to bug-readline@gnu.org
or bash-maintainers@gnu.org if patching the system libreadline
doesn't help.

The fix isn't don't use bash: That's the work-around until readline
gets patched.

This problem has been reported in other programs besides bash and
may be an issue in other shells (which use readline).


-- 
 Allan Fields                                       _.^.  ,_ ,. ._ .
 Afields Research/AFRSL - http://afields.ca        <,'/-\/- /\'_| /_
 BSDCan: May 2004, Ottawa - http://www.bsdcan.org   `'|'====-=--- -- -
                                                      `---- -- -
Comment 6 Volker Stolz freebsd_committer 2004-07-20 17:32:25 UTC
State Changed
From-To: open->analyzed

Really a readline issue which is understood to be indeed a bug 


Comment 7 Volker Stolz freebsd_committer 2004-07-20 17:32:25 UTC
Responsible Changed
From-To: obrien->ache

Over to readline-maintainer in base. I also cc'ed the devel/readline-maintainer.
Comment 8 Frank J. Laszlo 2004-07-20 19:23:45 UTC
I will look into the patch for readline, though I only maintain the 
updated readline port (made for FreeBSD 4.x users) I see most of you are 
using 5.x, which allready has readline 4.3 in base. I suggest submiting 
a patch to the responsible party for readline. Thanks for bringing this 
to my attention.

-Frank Laszlo
Comment 9 Frank J. Laszlo 2004-07-20 20:54:09 UTC
see http://www.freebsd.org/cgi/query-pr.cgi?pr=69352 for patch.

-Frank Laszlo
Comment 10 Volker Stolz freebsd_committer 2004-07-22 06:40:39 UTC
State Changed
From-To: analyzed->closed

readline in -base already contains the fix, an update for devel/readline 
has been submitted. Thanks for your submission!