| |
Home • About Us • A-Z Index • Search * Contact Us • Register • Login • Press • ShopThe Open Brand -- Problem Reporting and Interpretations System |
|
Problem Report 1401 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 1401.
Report 1401 Actions
Problem Report Number 1401 Submitter's Classification Test Suite problem State Resolved Resolution Test Suite Deficiency (TSD) Problem Resolution ID TSD.X.0683 Raised 1970-01-01 08:00 Updated 2003-03-13 08:00 Published 1996-05-30 08:00 Product Standard Internationalised System Calls and Libraries Extended (UNIX 95) Certification Program The Open Brand certification program Test Suite VSU version 4.1.0 Test Identification base/swapcontext 1 Problem Summary TSD4U.00132 This test may fail on IUTs which require a call to makecontext() as a part of defining an allocated stack for a context. Problem Text
Test program outline:
As currently implemented the test has the following outline:
1. second_time=0;
2. getcontext(&ucp);
3. if ( !second_time ) {
4. second_time=1;
5. modify ucp.uc_stack.{ss_sp,ss_size,ss_flags}
6. swapcontext(&ucp1,&ucp);
7. PASS ;
}
8. if (second_time++ = 1)
9. setcontext(&ucp1);
10. FAIL;
The test does a getcontext and stores the result in ucp.
Since second_time is initally 0, lines 4,5, and 6 are executed.
The expectation of the test program is that when line 6 is executed,
the swapcontext() call will transfer control to line 3, using the
stack supplied at line 5.
If this happens per the expectation of the test program, then the
boolean test at line 3 will fail and lines 8 and 9 will be executed.
When line 9 is executed, control will transfer back to line 7, and
the test will pass.
The test program expects that modification of ucp.uc_stack fields is
sufficient for the new stack to be used when the context stored in ucp
is resumed by the swapcontext() call.
Problem Description #1:
The test program has made an assumption that modifying the three stack
fields, {ss_sp,ss_size,ss_flags}, is sufficent on all implementation to
generate a valid stack structure. We believe that this is an assumption
that is not supported by the XSH specification (re: <signal.h>, <ucontext.h>).
The ucontext.h header defines (page 853) that the ucontext_t type as a
structure includes the type:
stack_t uc_stack the stack used by this context
The signal.h header defines (page 796) that the stack_t type as a structure
"includes at least the following members:" *ss_sp, ss_size, and ss_flags.
The specification does not disallow implementations from defining fields other
than those listed, in fact, it indicates that the possibility exists that
other members could be present.
Our implementation does define other members to define a valid stack.
Modifying
only the indicated stack members without regard to our implementation defined
members results in a corrupt stack, and thus a corrupt context structure.
Problem Description #2:
The test program has made an assumption that allocating a stack by modifying
the ucp.ss_<stack> fields (sp, size, flags), without a call to makecontext(),
will always result in a legal context that can be resumed using swapcontext().
We believe that this is an assumption not supported by the XSH specification
(re: getcontext(), makecontext(), and swapcontext() descriptions).
For the swapcontext() interface, the specification is not clear and does not
indicate what the legal sources of the ucp argument are, other than that
supplied from makecontext(). There is referenced in the following (XSH,
page 377):
``The makecontext() function modifies the context specified
by ucp, which has been initialized using getcontext(). When this
context is resumed by swapcontext() or setcontext().... ''
How does this relate to Problem Description #1? If a user attempts to
modify the context structure, a call to our implementation of makecontext()
will validate/modify the ucp context making it usable for swapcontext().
Is the ucp modified by makecontext() the only source of a legal swapcontext
ucp argument? We believe that the specification is silent on this issue
and as such, conformance distinctions based on any other assumptions can
not be made.
Possible Supporting References:
Additional descriptions for valid ucp arguments are found in the setcontext
interface (and a case could be made to apply them to swapcontext(). Although
this is also not defined by the specification). It is clearly specified that
the ucp argument should be obtained from one of the following sources (XSH,
page 228):
1. From a prior call to getcontext().
2. From being passed as an argument to a signal handler.
3. Created by makecontext.
Further, the specification for setcontext() states that "effects of passing
a ucp argument obtained from any other source are unspecified" (XSH, page 228).
Problem Summary, Suggested Fix, and Workaround:
We assert that there is a test defect with the swapcontext #1 test. It has
to do with the context which is being passed to swapcontext(). We assert that
the specification only defines a valid context for swapcontext() as one which
has been modified by makecontext() or unmodified from getcontext().
We suggest that a call to makecontext() be inserted after the context's stack
is modified. We believe that this will bring the testcase in line with the
specification.
Why wasn't this found in previous releases of the VSU tests? This test case in
previous releases of the VSU tests was non-functunal due to the "second_time"
variable not being defined as static. See TSD4U.00032
Test Output
TEST CASE: swapcontext
Test Purpose: #1
15|0 1.10 1|TCM Start
400|0 1 1 16:26:52|IC Start
200|0 1 16:26:52|TP Start
520|0 1 4305 1 1|SPEC1170TESTSUITE CASE 1
520|0 1 4305 1 2|A successful call to int swapcontext(ucontext_t *oucp,
520|0 1 4305 1 3|const ucontext_t *ucp) shall save the current context
520|0 1 4305 1 4|in the context structure pointed to by oucp, set the
520|0 1 4305 1 5|context to the context structure pointed to by ucp,
520|0 1 4305 1 6|and return 0.
520|0 1 4306 1 1|PREP: Generate a new context
520|0 1 4306 1 2|TEST: Context set to new context
520|0 1 4306 1 3|TEST: Original context saved in oucp
520|0 1 4305 2 1|ERROR: TEST TERMINATED DUE TO SIGSEGV SIGNAL (11)
220|0 1 1 16:26:52|FAIL
410|0 1 1 16:26:52|IC End
Depending on the processor type in use, the following test results may
also be experienced. It depends on how the corrupt context structure
is interpreted.
15|0 1.10 1|TCM Start
400|0 1 1 15:04:45|IC Start
200|0 1 15:04:45|TP Start
520|0 1 1938 1 1|SPEC1170TESTSUITE CASE 1
520|0 1 1938 1 2|A successful call to int swapcontext(ucontext_t *oucp,
520|0 1 1938 1 3|const ucontext_t *ucp) shall save the current context
520|0 1 1938 1 4|in the context structure pointed to by oucp, set the
520|0 1 1938 1 5|context to the context structure pointed to by ucp,
520|0 1 1938 1 6|and return 0.
520|0 1 1939 1 1|PREP: Generate a new context
520|0 1 1939 1 2|TEST: Context set to new context
520|0 1 1939 1 3|TEST: Original context saved in oucp
520|0 1 1938 2 1|ERROR: Test took longer than 600 seconds: presuming
520|0 1 1938 2 2| function is hung and terminating test
220|0 1 1 15:14:45|FAIL
410|0 1 1 15:14:45|IC End
Review Information
Review Type TSMA Review Start Date null Completed null Status Complete Review Recommendation No Resolution Given Review Response
We recommend this request be sent for review.
Historically, new context stacks have been allocated by setting
the stack_t members required by the spec (ss_sp, ss_size and
ss_flags). This method currently works for contexts passed to
makecontext(), setcontext() and swapcontext() on all our qa
platforms.
Whether the current spec meant to maintain this practice, mandate
the makecontext() call the submitter suggests, or require
something entirely different is not clear.
In our opinion 2 separate issues need clarified
* Are all contexts identical and available for use
by setcontext(), makecontext() and swapcontext()?
* Exactly how is a valid context with an allocated
stack generated?
Review Type SA Review Start Date null Completed null Status Complete Review Resolution No Resolution Given Review Conclusion
We believe that this request has merit but as it is based on a question
of the intent of the specification we would like the view of the Base
Working Group.
Review Type Expert Group Review Start Date null Completed null Status Complete Review Resolution No Resolution Given Review Conclusion
The specification is intentionally silent in this area and the test suite
should not assume how a context can be made.
A test suite deficiency should be granted.
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 1401
- List All PRs
- Search Reports
- Email the System Administrator
- View the The Open Brand Interpretations Database User Manual
Contact the Certification Authority