*Synopsis*: (while true ; do true | true ; done) hang in ioctl() with SIGTTOU
Due to a change requested by <User 1-5Q-9201>,
<User 1-5Q-9201> is now the responsible engineer for:
CR 6900314 changed on Jan 20 2010 by <User 1-5Q-9201>
=== Field ============ === New Value ============= === Old Value =============
Hook 5 <email address omitted>
Keyword oss-sponsor
Responsible Engineer <User 1-5Q-9201>
Status 3-Accepted 1-Dispatched
SubType Functionality
Targeted Release solaris_nevada
Type Defect RFE
====================== =========================== ===========================
*Change Request ID*: 6900314
*Synopsis*: (while true ; do true | true ; done) hang in ioctl() with SIGTTOU
Product: solaris
Category: shell
Subcategory: korn93
Type: Defect
Subtype: Functionality
Status: 3-Accepted
Substatus:
Priority: 1-Very High
Introduced In Release:
Introduced In Build:
Responsible Engineer: <User 1-5Q-9201>
Keywords: opensolaris, oss-request, oss-sponsor
=== *Description* ============================================================
Category
solaris/shell (Solaris Utilities/Commands)
Sub-Category
korn93
Description
This bug was reported at
http://mail.opensolaris.org/pipermail/shell-discuss/2009-October/000898.html
Just came through the shell list on opensolaris.org.
I can confirm that the bug occurs for simple statements like:
<email address omitted>:~/ksh93/docsvn/doc$ (while true ; do true | true ;
done)
^Z^Z^Z^Z^Z^C
<email address omitted>:~/ksh93/docsvn/doc$ jobs
[1] + Stopped(SIGTTOU) (while true ; do true | true ; done)
Multiple attempts to stop the process failed and the ^C didn't kill
it. The process is hanging in a ioctl() call:
<email address omitted>:~/ksh93/docsvn/doc$ pstack 27378
27378: -ksh93
ffffffff7f0c7c70 ioctl (2, 7415, ffffffff7fffb38c)
ffffffff7d94a4c0 job_set (100125680, ffffffff7daa9720, 3720, 7067,
15bbd4, 3400) + 98
ffffffff7d94bce8 job_wait (7067, 7067, 0, 0, 0, 0) + 1b4
ffffffff7d983d74 sh_exec (0, ffffffff7ecee3e8, 1001232e0,
ffffffff7daa8f08, 7067, 100000000) + 2d14
ffffffff7d98428c sh_exec (48e, 20a, 48e, ffffffff7fffccd0, 2, 100109790) + 322c
ffffffff7d984db8 sh_exec (0, 1, 0, 4, 0, 0) + 3d58
ffffffff7d97d1c0 sh_subshell (100109580, 4, 4, 4, 4, 3400) + 5c8
ffffffff7d984030 sh_exec (4, 24, 0, a0, 0, 100109550) + 2fd0
ffffffff7d95c0f4 exfile (ffffffff7daa8f08, ffffffff7daa8f08,
100109550, 24, 34, 34) + be8
ffffffff7d95b4f0 sh_main (20, 840a01210030, 0, ffffffff7daa8f08, 0,
ffffffff7daa6000) + c80
0000000100000d58 main (1, ffffffff7ffffc98, ffffffff7ffffca8, 1f3ee8,
1c80, 10000) + 44
0000000100000cfc _start (0, 0, 0, 0, 0, 0) + 17c
---------- Forwarded message ----------
From: Kyle McDonald <<email address omitted>>
Date: Oct 28, 2009 6:35 PM
Subject: [osol-discuss] KSH93 problem?
To: <email address omitted>, opensolaris-discuss
<<email address omitted>>
[Resend to opensolaris-discuss too.]
Hi!
Yesterday while debugging a shell script I think I may have found a bug
in ksh93 from sNV b124.
The script is basically checking a large list of DNS hostnames for ones
that already end in a '.'. I've boiled it down to a simpler test case:
while true; do if ! echo gretsch-p21-396 | grep '\.$'; then true; else
echo false; fi; done
If I run the above line at the shell prompt, for a long period of time I
get no ouput at all, which is to be expected. However, pretty regularly
rhe shell will be 'stopped' (as if I'd hit CTRL-Z) and I'll be returned
to my login shell.
If I continue the test by typing 'fg', then eventually, that 'if'
statement will actually echo 'false' to stdout. In my original script
that was having issues, I only ever saw the 'if' take the wrong path,
and I never saw this 'Stopped' problem. What could cause the system to
send 'SIGSTOP' to the ksh93 process?
Here is a sample:
> >while true; do if ! echo gretsch-p21-396 | grep '\.$'; then true;
> else echo false; fi; done
>
> [1]+ Stopped ksh93
> 37>fg
> ksh93
> false
>
> [1]+ Stopped ksh93
> 38>fg
> ksh93
>
> [1]+ Stopped ksh93
> 39>fg
> ksh93
>
> [1]+ Stopped ksh93
> 40>fg
> ksh93
>
> [1]+ Stopped ksh93
> 41>fg
> ksh93
>
> [1]+ Stopped ksh93
> 42>fg
> ksh93
>
> [1]+ Stopped ksh93
> 43>
Is it me, or is this wierd?
-Kyle
Frequency
Always
Regression
No
Steps to Reproduce
I've boiled it down to a simpler test case:
while true; do if ! echo gretsch-p21-396 | grep '\.$'; then true; else
echo false; fi; done
If I run the above line at the shell prompt, for a long period of time I
get no ouput at all, which is to be expected. However, pretty regularly
rhe shell will be 'stopped' (as if I'd hit CTRL-Z) and I'll be returned
to my login shell.
If I continue the test by typing 'fg', then eventually, that 'if'
statement will actually echo 'false' to stdout. In my original script
that was having issues, I only ever saw the 'if' take the wrong path,
and I never saw this 'Stopped' problem. What could cause the system to
send 'SIGSTOP' to the ksh93 process?
Here is a sample:
> >while true; do if ! echo gretsch-p21-396 | grep '\.$'; then true; else echo
> >false; fi; done
> [1]+ Stopped ksh93
> 37>fg
> ksh93
> false
>
> [1]+ Stopped ksh93
> 38>fg
> ksh93
>
> [1]+ Stopped ksh93
> 39>fg
> ksh93
>
> [1]+ Stopped ksh93
> 40>fg
> ksh93
>
> [1]+ Stopped ksh93
> 41>fg
> ksh93
>
> [1]+ Stopped ksh93
> 42>fg
> ksh93
>
> [1]+ Stopped ksh93
> 43>
>
Expected Result
-
Actual Result
-
Error Message(s)
-
Test Case
-
Workaround
Additional configuration information
*** (#1 of 1): 2009-11-11 17:39:31 GMT+00:00 <User 1-F4SZV>
=== *Public Comments* ========================================================
=== *Workaround* =============================================================
=== *Additional Details* =====================================================
Targeted Release: solaris_nevada
Commit To Fix In Build:
Fixed In Build:
Integrated In Build:
Verified In Build:
See Also: 6793763
Duplicate of:
Hooks:
Hook1:
Hook2:
Hook3:
Hook4:
Hook5: <email address omitted>
Hook6: <email address omitted>
Program Management:
Root Cause:
Fix Affects Documentation: No
Fix Affects Localization: No
=== *History* ================================================================
Date Submitted: 2009-11-11 17:39:30 GMT+00:00
Submitted By: <User 1-F4SZV>
Status Changed Date Updated Updated By
3-Accepted 2010-01-20 21:51:13 GMT+00:00 <User 1-5Q-9201>
=== *Service Request* ========================================================
Impact: Critical
Functionality: Primary
Severity: 1
Product Name: solaris
Product Release: solaris_nevada
Product Build: snv_01
Operating System: solaris_nevada
Hardware: generic
Submitted Date: 2009-11-11 17:39:31 GMT+00:00
=== *Multiple Release (MR) Cluster* - 0 ======================================
