Bug 584704 - Return of a command substitution from within another command substitution causes stdin of coprocess to be closed in a ksh script
Return of a command substitution from within another command substitution cau...
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: ksh (Show other bugs)
5.4
All Linux
medium Severity medium
: rc
: ---
Assigned To: Michal Hlavinka
qe-baseos-tools
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2010-04-22 04:36 EDT by Tomas Smetana
Modified: 2012-02-21 00:49 EST (History)
4 users (show)

See Also:
Fixed In Version: ksh-20100621-1.el5
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 584007
Environment:
Last Closed: 2012-02-21 00:49:34 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2012:0159 normal SHIPPED_LIVE ksh bug fix and enhancement update 2012-02-20 09:53:47 EST

  None (edit)
Description Tomas Smetana 2010-04-22 04:36:24 EDT
+++ This bug was initially created as a clone of Bug #584007 +++

Description of problem:
Return of a command substitution from within another command substitution causes stdin of coprocess to be closed in a ksh script.

Version-Release number of selected component (if applicable):
ksh-20100309-3.fc14.x86_64

How reproducible:
Always

Steps to Reproduce:
1. Execute the following script in ksh:

#######################################
#!/bin/ksh

set -e

co_process()
{
    while read line
    do
    printf "\n%s(): Read line from 'stdin'\n" "${.sh.fun}" >/dev/tty
    done
    printf "\n%s(): Exiting -- EOF on read of 'stdin'.\n" "${.sh.fun}" >/dev/tty
    # kill the main shell process when the end-of-file is detected on 'stdin'.
    kill $$
}

co_process |&

loop_count=0

while :
do
    (( loop_count++ ))
    printf "%05d: %s\r" "${loop_count}" "$( echo $( /bin/ls ) )"
done 
#######################################

Actual results:

Script ends with the following output:

test_script.ksh: Exiting -- EOF on read of 'stdin'.\n

Expected results:

Script should run in an infinite loop.

Additional info:

--- Additional comment from spoyarek@redhat.com on 2010-04-20 09:50:50 EDT ---

Created an attachment (id=407821)
Close coprocess file descriptors only if the coprocess pid is nonzero

The root cause for this is the race condition between the job_reap called within the signal handler and job_wait in the parent process. job_reap sets the lastpid to the pid of the process that exited last, so if job_wait is called after it, it correctly compares a valid pid against the coprocess pid to see if it is the coprocess that has ended.

But in case of a command substitution, the job env (including the coprocess pid) is backed up and reinitialized, hence making the coprocess pid 0. In this case, if job_wait happens to execute before job_reap, it compares the 0 coprocess id with the 0 lastpid (since it has not been set through the signal handler yet) and goes on to close the coprocess assuming that it has quit.

Attached fix ensures that the coprocess pid is actually set before trying to close its handlers.

--- Additional comment from mhlavink@redhat.com on 2010-04-20 10:38:50 EDT ---

Hi,

thanks for the report and especially for the patch. I can reproduce this bug and confirm attached patch fixes it. I've emailed all information to upstream and I'm waiting for their response.
Comment 5 RHEL Product and Program Management 2010-08-09 14:41:07 EDT
This request was evaluated by Red Hat Product Management for
inclusion in the current release of Red Hat Enterprise Linux.
Because the affected component is not scheduled to be updated in the
current release, Red Hat is unfortunately unable to address this
request at this time. Red Hat invites you to ask your support
representative to propose this request, if appropriate and relevant,
in the next release of Red Hat Enterprise Linux.
Comment 7 RHEL Product and Program Management 2011-01-11 16:10:04 EST
This request was evaluated by Red Hat Product Management for
inclusion in the current release of Red Hat Enterprise Linux.
Because the affected component is not scheduled to be updated in the
current release, Red Hat is unfortunately unable to address this
request at this time. Red Hat invites you to ask your support
representative to propose this request, if appropriate and relevant,
in the next release of Red Hat Enterprise Linux.
Comment 8 RHEL Product and Program Management 2011-01-11 17:43:26 EST
This request was erroneously denied for the current release of
Red Hat Enterprise Linux.  The error has been fixed and this
request has been re-proposed for the current release.
Comment 9 RHEL Product and Program Management 2011-05-31 09:45:34 EDT
This request was evaluated by Red Hat Product Management for
inclusion in the current release of Red Hat Enterprise Linux.
Because the affected component is not scheduled to be updated in the
current release, Red Hat is unfortunately unable to address this
request at this time. Red Hat invites you to ask your support
representative to propose this request, if appropriate and relevant,
in the next release of Red Hat Enterprise Linux.
Comment 12 errata-xmlrpc 2012-02-21 00:49:34 EST
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2012-0159.html

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