Bug 157260 - a certain command makes bash coredump
Summary: a certain command makes bash coredump
Alias: None
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: bash
Version: 4.0
Hardware: i386
OS: Linux
Target Milestone: ---
: ---
Assignee: Tim Waugh
QA Contact: Ben Levenson
Depends On:
Blocks: 181409
TreeView+ depends on / blocked
Reported: 2005-05-09 21:36 UTC by John Smith
Modified: 2012-06-21 13:55 UTC (History)
0 users

Fixed In Version: RHBA-2006-0332
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2006-08-10 21:16:33 UTC
Target Upstream Version:

Attachments (Terms of Use)
backtrace (3.14 KB, application/octet-stream)
2005-05-10 13:49 UTC, John Smith
no flags Details

System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2006:0332 0 normal SHIPPED_LIVE bash bug fix update 2006-08-09 04:00:00 UTC

Description John Smith 2005-05-09 21:36:23 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; rv:1.7.7) Gecko/20050417 Fedora/1.7.7-1.3.1

Description of problem:
The following command makes bash coredump.

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

How reproducible:

Steps to Reproduce:
cat <$(cat $(which bash))

Actual Results:  Segmentation fault

Expected Results:  No segmentation fault

Additional info:

Comment 1 Tim Waugh 2005-05-10 08:34:08 UTC
With bash-3.0-30 (Fedora devel) on x86_64 I get this:

$ cat <$(cat $(which bash))
bash: $(cat $(which bash)): ambiguous redirect

so it's possible it's fixed since Fedora Core 3.  However, I'd like to be sure.

Please install the bash-debuginfo-3.0-18 package from


and then run bash like this:

At the $ prompt: gdb bash
At the (gdb) prompt: run

Then type your command and make it crash.  Then get the strack trace like this:

At the (gdb) prompt: bt

What does it say?

Comment 2 John Smith 2005-05-10 11:45:05 UTC
Actually, it's a bit strange, I said that bash coredumps but
it's still running afterwards.  Here's what happens:

$ echo $SHELL $$
/bin/bash 4670
$ ls
$ ulimit -c 10000
$ cat <$(cat $(which bash))
Segmentation fault (core dumped)
$ echo $SHELL $$
/bin/bash 4670
$ ls
$ file core.4730 
core.4730: ELF 32-bit LSB core file Intel 80386, version 1 (SYSV), SVR4-style,
SVR4-style, from 'bash'

The core does come from bash.  I don't know what exactly happens
when the crashing command gets executed but the initial bash does
not crash, so when I apply your recipe, I don't get the gdb prompt
back (unless of course I exit from bash, in which case there is no

Comment 3 Tim Waugh 2005-05-10 13:02:19 UTC
I expect that it's one of the sub-processes that sefaults then.  Please do this:

gdb /bin/bash core.4730

and then enter 'bt' at the (gdb) prompt.  Thanks.

Comment 4 John Smith 2005-05-10 13:49:42 UTC
Created attachment 114203 [details]

OK, attached is the output of gdb.

Comment 5 Tim Waugh 2005-05-10 14:53:35 UTC

Comment 6 Tim Waugh 2005-05-10 16:10:50 UTC
Okay, I see it here too on a different machine.  The multibyteifs patch had a
small bug.

Fixed in 3.0-31 in Fedora development.  Thanks for the report.

Comment 18 Bob Johnson 2006-04-11 17:09:31 UTC
This issue is on Red Hat Engineering's list of planned work items 
for the upcoming Red Hat Enterprise Linux 4.4 release.  Engineering 
resources have been assigned and barring unforeseen circumstances, Red 
Hat intends to include this item in the 4.4 release.

Comment 22 Red Hat Bugzilla 2006-08-10 21:16:33 UTC
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.


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