| |
Home • About Us • A-Z Index • Search * Contact Us • Register • Login • Press • ShopThe Open Brand -- Problem Reporting and Interpretations System |
|
Problem Report 0267 Details
Show help | Quick Search | Submit a Test Suite Support Request | Click here to view your privileges
This page provides all information on Problem Report 0267.
Report 0267 Actions
Problem Report Number 0267 Submitter's Classification Test Suite problem State Resolved Resolution Test Suite Deficiency (TSD) Problem Resolution ID TSD.X.0267 Raised 1997-10-09 08:00 Updated 2003-03-13 08:00 Published 1997-10-14 08:00 Product Standard Internationalised System Calls and Libraries (XPG4) Certification Program The Open Brand certification program Test Suite VSX4 version 4.3.6 Test Identification POSIX.os/procprim/sigconcept 35 Problem Summary TSD4.267 We believe that there is a fault in the test suite for T.sigconcept test #35. Below is an explanation why we think this is so. There is currently a waiver for this test failure called PIN4.043, howeve... Problem Text
We believe that there is a fault in the test suite for T.sigconcept test #35.
Below is an explanation why we think this is so. There is currently a waiver
for this test failure called PIN4.043, however, the output described with
this waiver is different than the output we are getting. We are requesting
that a new and separate waiver be granted.
This note is to provide further clarification as to why we feel
our failure of POSIX.os/procprim/sigconcept Test No: 35 fall
under the interpretation of PIN4.043.
Briefly to recap the test, and what occurs on our system running
the test.
A process forks. The child process sets up a handler for SIGCONT,
while SIGTSTP remains with default disposition. The child then
starts an open on a named pipe, with O_RDONLY mode, which causes
the child to block on that operation, since there is no writer
for the pipe.
The parent then sends SIGTSTP to the child. After that, the
parent attempts to open the named pipe with mode bits O_WRONLY and
O_NONBLOCK. In our kernel, this open fails with ENXIO, which the
test does not expect. This is the only failure that occurs
in our run of sigconcept test no 35.
The parent then sends SIGCONT to the child, and the child
is interrupted from the system call with EINTR.
Why the test works this way in our system is due to the fact
that our kernel is designed to run in a multi-node multi-processor
configuration. What we do in our kernel, when the child is sent
SIGTSTP, is we make note of the fact that since the
child is catching SIGCONT, the only possible outcome of the
fifo open is to complete with EINTR. So we essentially fail the
system call at that point (quite correctly) although the child
remains suspended due to the SIGTSTP, until the SIGCONT is received.
Thus, due to the childs (eventual, but certain) failure of the
system call with EINTR, the parent's open also fails, with ENXIO,
as required by POSIX and XPG4.
As an aside, in an earlier exchange, there was some question as
to whether the child failed with EINTR. Indeed it does, as is
evidenced by this line from the system call trace:
722352mS[ 1] T.sigconcept( 2568): END-open() errno = 4
(Interrupted functioncall)
It is possible that this line may not have been in the trace we sent,
for which we apologize.
Why does this fit under PIN4.043?
The operation of our system in this instance is very similar to the
operation of the system described in PIN4.043 - that is, we allow
certain kernel operations to proceed after a process has been stopped.
That our kernel chooses to complete the childs open request differently
(and correctly - that is, terminating with EINTR) in this case than
does the system described in PIN4.043 is really immaterial.
The test itself expects the child to complete the open request
successfully while in the stopped state (thus allowing the
parent to complete its open request successfully), but to subsequently
fail with EINTR when continued. Nowhere is this particular
behavior described within POSIX or XPG4.
We will close by quoting several passages from PIN4.043 that we feel
are relevent to this issue.
"Neither POSIX nor XPG4 define interactions between asynchronous kernel
activities and process stopped status"
"The state of stopped kernel threads is not defined by XPG4 and should
not be relied on by applications."
"Again in the entry for open(), XPG4 states that when opening a fifo
with O_WRONLY and O_NONBLOCK set, the open() will return an error
if no process currently has the file open for (in the above case, the
VSX4 test assumes it will work even though the open for reading is
incomplete)."
Just to recap: our kernel allows certain events to proceed in the
kernel, though the thread is in a stopped state, as does the system
described in PIN4.043. Our system fails the childs open of the
fifo with EINTR at the time of TSTP, even though the process
remains suspended. This too is similar to the system described
in PIN4.043, though in that system, they choose the complete the
open system call successfully. This accounts for the different
output from the test in our system.Test Output
/tset/POSIX.os/procprim/sigconcept/T.sigconcept Test 35
=======================================================
520|589 35 71886 16 1|deletion reason - open() failed, errno 6
220|589 35 2 00:21:10|UNRESOLVEDReview Information
Review Type TSMA Review Start Date null Completed null Status Complete Review Recommendation No Resolution Given Review Response
We accept that this is a fault in the test suite and recommend that a
waiver is granted on the grounds of a test suite deficiency.
Review Type SA Review Start Date null Completed null Status Complete Review Resolution Test Suite Deficiency (TSD) Review Conclusion
This is an agreed Test Suite Deficiency.
Problem Reporting System Options:
- View Report 0267
- List All PRs
- Search Reports
- Email the System Administrator
- View the The Open Brand Interpretations Database User Manual
Contact the Certification Authority