HomeAbout Us A-Z IndexSearch * Contact Us Register LoginPress Shop

The Open Brand -- Problem Reporting and Interpretations System


Problem Report 2095 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 2095.


Report 2095 Actions


    Problem Report Number 2095
    Submitter's Classification Test Suite problem
    State Resolved
    Resolution Rejected (REJ)
    Problem Resolution ID REJ.X.0602
    Raised 1999-08-13 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.4
    Test Identification PTHR.os/all/pthread_mutex_init 2
    Problem Summary PG5TH.00009 The errors concerning T2_first are failures in our implementation and are not addressed by this request. Our concern is with: 520|0 2 000100308 17 1|Testing the recursive type attribute 520|0 2 000100...
    Problem Text

    The errors concerning T2_first are failures in our implementation and are
    not addressed by this request. Our concern is with:

    520|0 2 000100308 17 1|Testing the recursive type attribute
    520|0 2 000100308 17 2|pthread_mutex_unlock, expected 0, got 0

    This is a failure erroneously reported as a pass. The source is:

    /****** unlock an unlocked mutex ******/
    rval = pthread_mutex_unlock( &T2_mx8 );
    if ( rval == 0 )
    {
    vsth_surprise("pthread_mutex_unlock", 0, rval, NULL);
    (void) pthread_mutex_destroy( &T2_mx8 );
    exit(2);
    }

    In XSH5, p. 636, we have:

    The pthread_mutex_unlock() function may fail if:

    [EPERM] The current thread does not own the mutex.

    Since the failure "may fail", this test is implementation-dependent,
    and should be controlled by a flag in tetexec.cfg. In our implementation,
    it should fail with EPERM, and will fail this test once we fix it.

    Test Output


    200|0 2 14:18:26|TP Start
    520|0 2 000100304 1 1|A call to pthread_mutex_init(mutex, attr) initializes the mutex
    520|0 2 000100304 1 2|object referenced by mutex with the attributes specified b
    y attr
    520|0 2 000100304 1 3|and returns 0 if successful.
    520|0 2 000100304 1 4|Posix Ref: Component PTHREAD_MUTEX_INIT
    520|0 2 000100304 1 5|Assertion 9945-1:1996 11.3.2.2-2(A)
    520|0 2 000100304 1 6|Testing the prioceiling attribute
    520|0 2 000100304 1 7|Testing the PTHREAD_PRIO_PROTECT protocol
    520|0 2 000100304 5 1|T2_first, expected 0, got 1
    520|0 2 000100304 5 2|Testing the PTHREAD_PRIO_INHERIT protocol
    520|0 2 000100304 11 1|T2_first, expected 0, got 1
    520|0 2 000100304 11 2|Testing the process shared attribute
    520|0 2 000100304 15 1|Testing the type attributes
    520|0 2 000100306 15 1|Testing the normal type attribute
    520|0 2 000100307 16 1|Testing the errorcheck type attribute
    520|0 2 000100307 16 2|Unlocking an unlocked mutex unexpectedly succeeded
    520|0 2 000100308 17 1|Testing the recursive type attribute
    520|0 2 000100308 17 2|pthread_mutex_unlock, expected 0, got 0
    520|0 2 000100309 18 1|Testing the default type attribute
    220|0 2 1 14:18:33|FAIL
    410|0 2 1 14:18:33|IC End

    Review Information

    Review Type TSMA Review
    Start Date null
    Completed null
    Status Complete
    Review Recommendation No Resolution Given
    Review Response
    There is a problem with the test suite but not for the reason
    given. The test code is putting out an erroneous expected 0 got 0
    message but is testing the correct behaviour, the unlocking of an
    unlocked mutex in this case is required to fail as per the following
    section of the EX shaded text from the pthread_mutex_lock() man page:

    If the mutex type is PTHREAD_MUTEX_RECURSIVE, then the mutex
    maintains the concept of a lock count. When a thread successfully
    acquires a mutex for the first time, the lock count is set to
    one. Every time a thread relocks this mutex, the lock count is
    incremented by one. Each time the thread unlocks the mutex,
    the lock count is decremented by one. When the lock count
    reaches zero, the mutex becomes available for other threads to
    acquire. If a thread attempts to unlock a mutex that it has not
    locked or a mutex which is unlocked, an error will be returned.

    The following correction to the error output message will be applied
    in a future release of the test suite:

    *** pthread_mutex_init.c.orig Tue Aug 17 14:18:46 1999
    --- pthread_mutex_init.c Tue Aug 17 14:32:32 1999
    ***************
    *** 1509,1516 ****
    rval = pthread_mutex_unlock( &T2_mx8 );
    if ( rval == 0 )
    {
    ! vsth_surprise("pthread_mutex_unlock", 0, rval, NULL);
    ! (void) pthread_mutex_destroy( &T2_mx8 );
    exit(2);
    }

    --- 1509,1516 ----
    rval = pthread_mutex_unlock( &T2_mx8 );
    if ( rval == 0 )
    {
    ! tet_infoline("Unlocking an unlocked mutex unexpectedly
    succeeded ");

    ! (void) pthread_mutex_destroy( &T2_mx8 );
    exit(2);
    }


    The description has a clear requirement for the error to be returned,
    yet the ERRORS description has omitted to state which error, as such
    the test does not check for any particular error.
    It is recommended that this waiver 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