[1003.1(2008)/Issue 7 0000610]: Possible race condition in requirements of exit and their interaction with threads.
The following issue has been RESOLVED. == https://austingroupbugs.net/view.php?id=610 == Reported By:dalias Assigned To:ajosey == Project:1003.1(2008)/Issue 7 Issue ID: 610 Category: System Interfaces Type: Clarification Requested Severity: Objection Priority: normal Status: Resolved Name: Rich Felker Organization: musl libc User Reference: Section:exit Page Number:unknown Line Number:unknown Interp Status: --- Final Accepted Text:https://austingroupbugs.net/view.php?id=610#c5947 Resolution: Accepted As Marked Fixed in Version: == Date Submitted: 2012-09-24 20:17 UTC Last Modified: 2022-08-25 16:30 UTC == Summary:Possible race condition in requirements of exit and their interaction with threads. == Issue History Date ModifiedUsername FieldChange == 2012-09-24 20:17 dalias New Issue 2012-09-24 20:17 dalias Status New => Under Review 2012-09-24 20:17 dalias Assigned To => ajosey 2012-09-24 20:17 dalias Name => Rich Felker 2012-09-24 20:17 dalias Organization => musl libc 2012-09-24 20:17 dalias Section => exit 2012-09-24 20:17 dalias Page Number => unknown 2012-09-24 20:17 dalias Line Number => unknown 2022-08-25 16:29 geoffclare Note Added: 0005947 2022-08-25 16:30 geoffclare Interp Status => --- 2022-08-25 16:30 geoffclare Final Accepted Text => https://austingroupbugs.net/view.php?id=610#c5947 2022-08-25 16:30 geoffclare Status Under Review => Resolved 2022-08-25 16:30 geoffclare Resolution Open => Accepted As Marked ==
[1003.1(2008)/Issue 7 0000610]: Possible race condition in requirements of exit and their interaction with threads.
A NOTE has been added to this issue. == https://austingroupbugs.net/view.php?id=610 == Reported By:dalias Assigned To:ajosey == Project:1003.1(2008)/Issue 7 Issue ID: 610 Category: System Interfaces Type: Clarification Requested Severity: Objection Priority: normal Status: Under Review Name: Rich Felker Organization: musl libc User Reference: Section:exit Page Number:unknown Line Number:unknown Interp Status: --- Final Accepted Text: == Date Submitted: 2012-09-24 20:17 UTC Last Modified: 2022-08-25 16:29 UTC == Summary:Possible race condition in requirements of exit and their interaction with threads. == -- (0005947) geoffclare (manager) - 2022-08-25 16:29 https://austingroupbugs.net/view.php?id=610#c5947 -- On 2018 edition page 796 line 27070, change:The exit() function shall then flush all open streams with unwritten buffered data and close all open streams. Finally, the process shall be terminated [CX]with the same consequences as described in [xref to Consequences of Process Termination][/CX].to:The exit() function shall then flush all open streams with unwritten buffered data. [CX]For each stream which is the active handle to its underlying file descriptor, and for which the file is not already at EOF and is capable of seeking, the file offset of the underlying open file description shall be set to the file position of the stream. For each open stream, the exit() function shall perform the equivalent of a close() on the file descriptor that is associated with the stream.[/CX] Finally, the process shall be terminated [CX]with the same consequences as described in [xref to Consequences of Process Termination][/CX]. Issue History Date ModifiedUsername FieldChange == 2012-09-24 20:17 dalias New Issue 2012-09-24 20:17 dalias Status New => Under Review 2012-09-24 20:17 dalias Assigned To => ajosey 2012-09-24 20:17 dalias Name => Rich Felker 2012-09-24 20:17 dalias Organization => musl libc 2012-09-24 20:17 dalias Section => exit 2012-09-24 20:17 dalias Page Number => unknown 2012-09-24 20:17 dalias Line Number => unknown 2022-08-25 16:29 geoffclare Note Added: 0005947 ==
[Issue 8 drafts 0001602]: No definition of "executed in a trap action"
A NOTE has been added to this issue. == https://austingroupbugs.net/view.php?id=1602 == Reported By:kre Assigned To: == Project:Issue 8 drafts Issue ID: 1602 Category: Shell and Utilities Type: Omission Severity: Objection Priority: normal Status: New Name: Robert Elz Organization: User Reference: Section:XCU 2.14 exit XCU 2.14 return Page Number:2369, 2379 Line Number:76750, 77069 Final Accepted Text: == Date Submitted: 2022-08-23 16:33 UTC Last Modified: 2022-08-25 15:49 UTC == Summary:No definition of "executed in a trap action" == -- (0005946) kre (reporter) - 2022-08-25 15:49 https://austingroupbugs.net/view.php?id=1602#c5946 -- There is another defect that we might want to fix as part of this issue. XCU 2.14/trap says The value of "$?" after the trap action completes shall be the value it had before the trap action was executed. yet it is quite clear (from any reading) that XCU 2.14/exit and XCU2.14/return mandate, than when given an explicit status to return, those two commands do alter the value of "$?" after the trap action completes (when one of those commands is the last executed in the trap action). That's deliberate, it allows an trap action like the following trap 'cleanup || exit 1' EXIT when invoked by exit 0 to cause the script to exit with status 1, rather than 0, in the event that cleanup failed. That is intended, and desirable, I think. The same applies to a trap action whose purpose is to make a function return with a specific value, regardless of what the value of $? might have been at the point in the function where the action was invoked. The wording above (from XCU 2.14/trap) needs to be corrected. Issue History Date ModifiedUsername FieldChange == 2022-08-23 16:33 kreNew Issue 2022-08-23 16:33 kreName => Robert Elz 2022-08-23 16:33 kreSection => XCU 2.14 exit XCU 2.14 return 2022-08-23 16:33 krePage Number => 2369, 2379 2022-08-23 16:33 kreLine Number => 76750, 77069 2022-08-23 18:11 kreNote Added: 0005941 2022-08-23 18:27 kreNote Added: 0005942 2022-08-25 01:10 hvdNote Added: 0005943 2022-08-25 15:20 kreNote Added: 0005945 2022-08-25 15:49 kreNote Added: 0005946 ==
[Issue 8 drafts 0001602]: No definition of "executed in a trap action"
A NOTE has been added to this issue. == https://austingroupbugs.net/view.php?id=1602 == Reported By:kre Assigned To: == Project:Issue 8 drafts Issue ID: 1602 Category: Shell and Utilities Type: Omission Severity: Objection Priority: normal Status: New Name: Robert Elz Organization: User Reference: Section:XCU 2.14 exit XCU 2.14 return Page Number:2369, 2379 Line Number:76750, 77069 Final Accepted Text: == Date Submitted: 2022-08-23 16:33 UTC Last Modified: 2022-08-25 15:20 UTC == Summary:No definition of "executed in a trap action" == -- (0005945) kre (reporter) - 2022-08-25 15:20 https://austingroupbugs.net/view.php?id=1602#c5945 -- Three responses to issues in https://austingroupbugs.net/view.php?id=1602#c5943 (in a different order than they appear there). First, wrt the proposed wording - yes, that looks like it would work, I didn't ever consider it that way. Provided that we actually want the wording for exit & return to be the same (which risks the later interpretation "we know what those words mean in case A, case B uses the same words, so they must mean the same thing there" which is OK if that really is the intent, but we need to be certain that the two are really meant to be identical in all respects, otherwise it can be better to use slightly different wording, and avoid that problem (that's why I varied the wording I used just a little, in the exit and return cases). Second, it wasn't anyone's work I was dismissing as absurd or insane, it is the result produced. That's is as true of the NetBSD sh doing it as any other shell - our shell (not mine, I'm just the current (major) maintainer but I wrote only a tiny fraction of the code in there) has done absurd things many times in the past, and almost certainly still does. They get fixed, eventually, when discovered, and if possible. But yes, I should have done a lot more testing of various shells, but other than using the EXIT trap (which cannot be used to test everything) actually running tests for this is difficult, as in a script, there's no way I know of, to force the "value for the special parameter '?' that is considered ``current'' shall be the value it had immediately preceding the trap action." to be any known value - and if we don't know what it is, we cannot test that it is being used when required (whenever we believe that to be). This is just due to the nature of the conditions which invoke trap actions, other than EXIT, when they occur is unpredictable. Interactively it is possible, as one can set an exit status, and then just do nothing, until after the trap action has occurred (sending the occasional \n to cause new prompts to be written, and allow the trap to happen). That works, but is ***slow*** and tedious to do. Hence I was prevaricating ... this defect report was discussed (in other places, and in private e-mail, in the early days of this month - and I had promised (just private e-mail I think) to submit this back then ... but waiting for me to get the energy to do more testing (or almost any testing) kept delaying it, and since there was no end in sight to that problem, I thought I should just go ahead anyway - test results can always be added as a note (like this) by me later (or by anyone else who can add notes, like hvd, as one example). And third, for the most complex one to reply to - this is going to take some time (ie: many lines following...) I think the current wording can be read to to meet my expectations, perhaps with just one minor change (I'd prefer to be incompat with any possible reading in this one way, but if that's unacceptable, it would not be fatal). Start by accepting that "executed in a trap action" might mean "the exit (or return, as appropriate) must appear literally in the action string of the trap command, for the condition which occurred, such that the action is invoked. Whether it does mean that is unknown, but since we are just looking for "any legitimate reading" this is certainly one possibility. Two problems arise from this, the first is the one I mention just above, which is that if we had
[1003.1(2008)/Issue 7 0000613]: Relationship of automatic object lifetimes to cancellation cleanup functions is not specified
The following issue has been RESOLVED. == https://austingroupbugs.net/view.php?id=613 == Reported By:dalias Assigned To:ajosey == Project:1003.1(2008)/Issue 7 Issue ID: 613 Category: System Interfaces Type: Omission Severity: Editorial Priority: normal Status: Resolved Name: Rich Felker Organization: musl libc User Reference: Section:pthread_cleanup_push Page Number:unknown Line Number:unknown Interp Status: --- Final Accepted Text:https://austingroupbugs.net/view.php?id=613#c5944 Resolution: Accepted As Marked Fixed in Version: == Date Submitted: 2012-09-24 21:41 UTC Last Modified: 2022-08-25 15:15 UTC == Summary:Relationship of automatic object lifetimes to cancellation cleanup functions is not specified == Issue History Date ModifiedUsername FieldChange == 2012-09-24 21:41 dalias New Issue 2012-09-24 21:41 dalias Status New => Under Review 2012-09-24 21:41 dalias Assigned To => ajosey 2012-09-24 21:41 dalias Name => Rich Felker 2012-09-24 21:41 dalias Organization => musl libc 2012-09-24 21:41 dalias Section => pthread_cleanup_push 2012-09-24 21:41 dalias Page Number => unknown 2012-09-24 21:41 dalias Line Number => unknown 2022-08-25 15:15 geoffclare Note Added: 0005944 2022-08-25 15:15 geoffclare Interp Status => --- 2022-08-25 15:15 geoffclare Final Accepted Text => https://austingroupbugs.net/view.php?id=613#c5944 2022-08-25 15:15 geoffclare Status Under Review => Resolved 2022-08-25 15:15 geoffclare Resolution Open => Accepted As Marked ==
[1003.1(2008)/Issue 7 0000613]: Relationship of automatic object lifetimes to cancellation cleanup functions is not specified
A NOTE has been added to this issue. == https://austingroupbugs.net/view.php?id=613 == Reported By:dalias Assigned To:ajosey == Project:1003.1(2008)/Issue 7 Issue ID: 613 Category: System Interfaces Type: Omission Severity: Editorial Priority: normal Status: Under Review Name: Rich Felker Organization: musl libc User Reference: Section:pthread_cleanup_push Page Number:unknown Line Number:unknown Interp Status: --- Final Accepted Text: == Date Submitted: 2012-09-24 21:41 UTC Last Modified: 2022-08-25 15:15 UTC == Summary:Relationship of automatic object lifetimes to cancellation cleanup functions is not specified == -- (0005944) geoffclare (manager) - 2022-08-25 15:15 https://austingroupbugs.net/view.php?id=613#c5944 -- After 2018 edition page 48 line 1520 section 3 Definitions, add a new definition: 3.xxx Code BlockIn the context of the System Interfaces Volume of this standard, a block as defined in the ISO C standard. After 2018 edition page 1605 line 52316 section pthread_cleanup_pop(), add a new paragraph:Invoking a cancellation cleanup handler may terminate the execution of any code block being executed by the thread whose execution began after the corresponding invocation of pthread_cleanup_push(). Issue History Date ModifiedUsername FieldChange == 2012-09-24 21:41 dalias New Issue 2012-09-24 21:41 dalias Status New => Under Review 2012-09-24 21:41 dalias Assigned To => ajosey 2012-09-24 21:41 dalias Name => Rich Felker 2012-09-24 21:41 dalias Organization => musl libc 2012-09-24 21:41 dalias Section => pthread_cleanup_push 2012-09-24 21:41 dalias Page Number => unknown 2012-09-24 21:41 dalias Line Number => unknown 2022-08-25 15:15 geoffclare Note Added: 0005944 ==
