|Summary:||a certain command makes bash coredump|
|Product:||Red Hat Enterprise Linux 4||Reporter:||John Smith <johnsmith7219>|
|Component:||bash||Assignee:||Tim Waugh <twaugh>|
|Status:||CLOSED ERRATA||QA Contact:||Ben Levenson <benl>|
|Fixed In Version:||RHBA-2006-0332||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2006-08-10 21:16:33 UTC||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Cloudforms Team:||---||Target Upstream Version:|
|Bug Depends On:|
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): bash-3.0-18 How reproducible: Always Steps to Reproduce: Type: 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 ftp://download.fedora.redhat.com/pub/fedora/linux/core/updates/3/i386/debug/ 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 core.4730 $ 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 backtrace).
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] backtrace 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. http://rhn.redhat.com/errata/RHBA-2006-0332.html