Bug 1176670
| Summary: | Problem with alarm and IFS | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 6 | Reporter: | Paulo Andrade <pandrade> | ||||||||
| Component: | ksh | Assignee: | Michal Hlavinka <mhlavink> | ||||||||
| Status: | CLOSED ERRATA | QA Contact: | Martin Kyral <mkyral> | ||||||||
| Severity: | unspecified | Docs Contact: | |||||||||
| Priority: | unspecified | ||||||||||
| Version: | 6.4 | CC: | baitken, joedward, mhlavink, mkolbas, mkyral, ovasik, pandrade | ||||||||
| Target Milestone: | rc | ||||||||||
| Target Release: | --- | ||||||||||
| Hardware: | Unspecified | ||||||||||
| OS: | Unspecified | ||||||||||
| Whiteboard: | |||||||||||
| Fixed In Version: | ksh-20120801-25.el6 | Doc Type: | Bug Fix | ||||||||
| Doc Text: |
Previously, ksh terminated unexpectedly after an alarm occurred during a read operation with a modified Internal Field Separator (IFS). The ksh alarm built-in has been modified to preserve the IFS table during execution. As a result, ksh no longer crashes in this situation.
|
Story Points: | --- | ||||||||
| Clone Of: | |||||||||||
| : | 1192118 1192119 1360483 (view as bug list) | Environment: | |||||||||
| Last Closed: | 2015-07-22 06:56:27 UTC | Type: | Bug | ||||||||
| Regression: | --- | Mount Type: | --- | ||||||||
| Documentation: | --- | CRM: | |||||||||
| Verified Versions: | Category: | --- | |||||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||||
| Embargoed: | |||||||||||
| Bug Depends On: | |||||||||||
| Bug Blocks: | 1360483, 1406448 | ||||||||||
| Attachments: |
|
||||||||||
Created attachment 972117 [details]
ksh-20120801-alarm.patch
This is the patch I propose to be applied on
rhel and fedora ksh packages.
Created attachment 972118 [details]
ksh-20120801-ifstable.patch
Minimal one liner patch that correct the problem.
This patch should be in upstream ksh now.
Created attachment 972126 [details]
ksh-20120801-ifstable.patch
Alternate simple patch, that should also be in upstream
now. This is a slightly simpler version of
ksh-20120801-alarm.patch
I don't understand it clearly from the comments. What patches were included upstream? Both 2 and 3? Sorry for somewhat confusing patches attached. The two patches named ksh-20120801-ifstable.patch should be in upstream, either corrects the problem (one overwrites the test condition that would cause an infinite loop, the other save and restore the ifstable during the alarm). There is no newer tarball at http://www2.research.att.com/sw/download/ so I cannot confirm to be 100% sure it has been added. The email from David Korn I did cut&paste is talking about the two patches named ksh-20120801-ifstable.patch that were posted to ast-users mailing list. The patch named ksh-20120801-alarm.patch is an attempt to save&restore more state in an alarm, but is likely incomplete, that is, there may be other states that should be save/restored for possible other issues, like exceptions, during the alarm, but no known test case. 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. https://rhn.redhat.com/errata/RHBA-2015-1450.html |
This problem is specific to all releases, and fedora, up to rawhide. A simple test case is: ---%<--- #!/bin/ksh toto="s" alarm -r alarm_handler +1 function alarm_handler.alarm { if [[ $toto == "s" ]] then toto="e" else toto="f" fi } IFS="," (echo "2";sleep 1;echo "3") | while IFS="," read arg1 #(echo "2";sleep 1;echo "3") | while read arg1 do print "$arg1" done ---%<--- There is a small thread about it at http://lists.research.att.com/pipermail/ast-users/2014q4/004684.html I had made an initial one liner patch that address specifically the problem, but I was not happy with it because it probably would just hide other issues that may arise from alarms. Anyway, I will only propose a simple patch for cases where there are no exceptions involved. This was an off list reply I received: ---%<--- [...] Subject: Re: [ast-users] [PATCH] Problem with alarm and IFS From: David Korn <dgkorn> To: =?UTF-8?Q?Paulo_C=C3=A9sar_Pereira_de_Andrade?= <paulo.cesar.pereira.de.andrade> Content-Type: multipart/alternative; boundary=001a113ab2ba6fd291050a9c0dcd --001a113ab2ba6fd291050a9c0dcd Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I never documented the alarm builtin because it is problematic. The problem is that traps can't safely be handled asynchronously. What should happen is that the trap is marked for execution (sh_trapnote) and run after the current command completes. The time trap should wake up the shell if it is blocked and it should return and then handle the trap. That being said, I will pick up both of our patches since they don't do harm and improve the undocumented alarm builtin. [...] ---%<---