Home • About Us • A-Z Index • Search * Contact Us • Register • Login • Press • Shop

The Open Brand -- Problem Reporting and Interpretations System

Problem Report 2024 Details

Help Show help | Quick Search | Submit a Test Suite Support Request | Click here to view your privileges

This page provides all information on Problem Report 2024.

Report 2024 Actions

    Problem Report Number 2024
    Submitter's Classification Test Suite problem
    State Resolved
    Resolution Rejected (REJ)
    Problem Resolution ID REJ.X.0597
    Raised 1970-01-01 08:00
    Updated 2003-03-13 08:00
    Published null
    Product Standard Internationalised System Calls and Libraries Extended V2 (UNIX 98)
    Certification Program The Open Brand certification program
    Test Suite VSTH version 5.1.2
    Test Identification PTHR.os/all/pthread_exit 3
    Problem Summary PG5TH.00004 POSIX96, 16.2.5.2, line 231, pthread_exit() states that "any cancellation handlers that have been pushed and not yet popped shall be popped in the reverse order that they were pushed and then executed...
    Problem Text

    POSIX96, 16.2.5.2, line 231, pthread_exit() states that "any cancellation
    handlers that have been pushed and not yet popped shall be popped in the
    reverse order that they were pushed and then executed". The standard also
    states that the cancellation cleanup push and pop handlers should happen within
    the same lexical scope [POSIX96, page 352, section 18.3.2.3, line 206-207].

    This raises the issue of what should be the specified behavior with
    respect to pthread_exit() when pthread_exit() is called implicitly,
    or explicitly by a thread that has returned from one of more scopes
    without popping the pushed cleanup handler.

    We believe that the lines quoted above from subclause 18.2.3.2 mean that any
    application that invokes pthread_cleanup_push() and leaves that scope without
    invoking pthread_cleanup_pop() is not a conforming application. The test
    suite is supposed to be a conforming application, but leaves the scope that
    invoked pthread_cleanup_push() without invoking pthread_cleanup_pop() before
    calling pthread_exit().

    The rationale for thread termination [POISX96, page 569, section B 16.2.5,
    line 8770-8782] only describes the case when pthread_exit() is called in the
    same scope where pthread_cleanup_push() and pthread_cleanup_pop() are invoked.

    When a thread returns from a scope, the assumption is that the thread is in
    consistent state. A cancelation handler is used within in a scope to make that




    scope cancellation safe. If the thread returns, then the scope should be
    consistent. Any lock that the scope was holding should be released. If it is
    not, then the thread is inconsistent.

    Test Output

    400|0 3 1 20:12:15|IC Start
    200|0 3 20:12:15|TP Start
    520|0 3 00013731 1 1|An implicit call to pthread_exit() is made when a thread
    other 520|0 3 00013731 1 2|than the thread in which main() was first invoked
    returns from 520|0 3 00013731 1 3|the start routine that was used to create
    it. 520|0 3 00013731 1 4|Posix Ref: Component PTHREAD_EXIT
    520|0 3 00013731 1 5|Assertion 9945-1:1996 16.2.5.2-3(A)
    520|0 3 00013731 2 1|T3_cflag, expected 2, got 0
    220|0 3 1 20:12:15|FAIL
    410|0 3 1 20:12:15|IC End

    Review Information

    Review Type TSMA Review
    Start Date null
    Completed null
    Status Complete
    Review Recommendation No Resolution Given
    Review Response
    This testcase tests that an implicit pthread_exit() is performed when
    a thread other than the main thread returns from it's start routine
    by checking that side-effects of a pthread_exit() occurs when the
    thread returns. The side effects tested are that cancellation cleanup
    handlers and destructors are called upon an implicit or explicit
    pthread_exit. To verify this, the test does the following:

    a) the main thread creates a second thread
    b) this second thread installs cancellation cleanup handlers and thread
    specific data destructors
    c) this second thread then performs a return from the start routine
    d) the main thread checks to ensure that the cancellation cleanup handlers and
    destructors were called by checking the value of two global variables.
    The cancellation cleanup handlers do not access data local in scope to
    t3_t1.

    Substantially simplified, the code looks like this:

    int T3_cflag;

    void
    t3_f1()
    {
    pthread_create(&tid, NULL, t3_t1, NULL);
    pthread_join(tid, &tval);

    /* check to ensure that CCH && TSDs were called for t3_t1 */
    ....
    ...
    }

    void *
    t3_t1( void *arg )
    {
    pthread_cleanup_push(t3_ch1, ...);
    pthread_key_create(...);
    pthread_key_setspecific(...);
    return(NULL);

    pthread_cleanup_pop(...);




    return(NULL);
    }

    void
    t3_ch1(void *arg)
    {
    ++T3_cflag;
    }

    This implementation fails this test because the cancellation cleanup
    handlers were not called, although this implementation did correctly call
    the thread specific data destructors.

    The requirement that cancellation cleanup handlers and destructors are
    called upon an explicit or implicit pthread_exit() is a clear requirement
    of the POSIX.1 standard, stated in sections 16.2.5.2 and further supported
    by a statement in the rationale in section B16.2.5.

    POSIX.1, page 340, lines 239 ... 241 states:
    "An implicit call to pthread_exit() is made when a thread other than
    the thread in which main() was first invoked returns from the
    start routine that was used to create it."

    POSIX.1, page 339-340, lines 231 .. 235 states, for pthread_exit():
    "Any cancellation cleanup handlers that have been pushed and not
    yet popped shall be popped ..."

    We disagree with the applicant's assertion that returning prior to
    a pthread_cleanup_pop() is a violation of the rules for conforming
    applications. If applications can not return from the start routine
    at any time, then it would be unnecessary for the POSIX standard to
    require that an implicit or explicit pthread_exit() invoke any
    cancellation cleanup handler pushed but not yet popped.

    We also disagree with the applicant's assertion that the statement in B16.2.5
    refers only to the case when pthread_exit() is called in the
    same scope where pthread_cleanup_push() and pthread_cleanup_pop() are invoked.
    No such statement is made.

    We recommend that this request be refused.


    Review Type SA Review
    Start Date null
    Completed null
    Status Complete
    Review Resolution Rejected (REJ)
    Review Conclusion
    This request is refused.

    Problem Reporting System Options:

     

    Back   

Contact the Certification Authority