Bug 157260 - a certain command makes bash coredump
a certain command makes bash coredump
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: bash (Show other bugs)
i386 Linux
low Severity high
: ---
: ---
Assigned To: Tim Waugh
Ben Levenson
Depends On:
Blocks: 181409
  Show dependency treegraph
Reported: 2005-05-09 17:36 EDT by John Smith
Modified: 2012-06-21 09:55 EDT (History)
0 users

See Also:
Fixed In Version: RHBA-2006-0332
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-08-10 17:16:33 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

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

  None (edit)
Description John Smith 2005-05-09 17:36:23 EDT
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 04:34:08 EDT
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 07:45:05 EDT
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 09:02:19 EDT
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 09:49:42 EDT
Created attachment 114203 [details]

OK, attached is the output of gdb.
Comment 5 Tim Waugh 2005-05-10 10:53:35 EDT
Comment 6 Tim Waugh 2005-05-10 12:10:50 EDT
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 13:09:31 EDT
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 17:16:33 EDT
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.