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

The Open Brand -- Problem Reporting and Interpretations System

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

Report 0185 Actions

    Problem Report Number 0185
    Submitter's Classification Test Suite problem
    State Resolved
    Resolution Test Suite Deficiency (TSD)
    Problem Resolution ID TSD.X.0185
    Raised 1994-08-18 08:00
    Updated 2003-03-13 08:00
    Published 1994-08-25 08:00
    Product Standard Internationalised System Calls and Libraries (XPG4)
    Certification Program The Open Brand certification program
    Test Suite VSX4 version 4.3.4
    Test Identification POSIX.os/ioprim/fcntl 15, 16
    Problem Summary TSD4.185 Some VSX fcntl() tests attempt to verify that adjacent fcntl() record locks are coalesced by the operating system into one lock. We believe that these tests are testing fcntl() locking characteristics...
    Problem Text
    Some VSX fcntl() tests attempt to verify that adjacent fcntl()
    record locks are coalesced by the operating system into one lock.

    We believe that these tests are testing fcntl() locking characteristics
    not specified by X/open or POSIX. POSIX states that the GETLK command
    must return a lock, however, since POSIX does not specify how the
    operating system should implement record locks, the only information
    that must be returned is that a lock exists on a given byte.

    We found XPG3 waivers for this problem (PG3san.146, PG3san.254,
    PG3san.501) but was unsure that any of these waivers could be used in
    XPG4 branding. We also found a reference to the XPG3 waivers in
    PG4Rsan.020 which agreed that the function of coalescing adjacent
    locks was not required. It was suggested that we submit a new request
    for a XPG4 waiver.

    The authors of the original waivers included tests 11, 12, 15, 16,
    and 23 in their list of tests failing but only tests 15 and 16 are
    failing on our implementation so those are the only ones we are
    requesting waivers for.

    This request was submitted once as req.4.2.413 which was refused and
    the consultant asked for more information:

    - From the test suite output, it is unclear at what point in the
    code the error was detected. The consultant suggested we use
    VSX_DBUG_FLAGS=d:F:L. Here is the debug output for test 15:

    fcntl1.c: 00564: test15: trace: path counter 1
    fcntl1.c: 00573: test15: trace: path counter 2
    fcntl1.c: 00584: test15: trace: path counter 3
    fcntl1.c: 00593: test15: trace: path counter 4
    fcntl1.c: 00606: test15: trace: path counter 5
    fcntl.c: 02605: fcn_to: trace: path counter 1
    fcntl1.c: 00638: pa_t15: trace: path counter 1
    fcntl1.c: 00648: pa_t15: trace: path counter 2
    fcntl1.c: 00791: ch_t15: trace: path counter 1
    fcntl1.c: 00802: ch_t15: trace: path counter 2
    fcntl1.c: 00810: ch_t15: trace: path counter 3
    fcntl.c: 02605: fcn_to: trace: path counter 1
    fcntl.c: 02410: tstlk: trace: path counter 1
    fcntl.c: 02417: tstlk: trace: path counter 2
    fcntl.c: 02513: cmp_lcks: trace: path counter 1
    fcntl.c: 02421: tstlk: trace: path counter 3
    fcntl1.c: 00816: ch_t15: trace: path counter 4
    fcntl1.c: 00826: ch_t15: trace: path counter 5
    fcntl1.c: 00658: pa_t15: trace: path counter 3
    fcntl.c: 02605: fcn_to: trace: path counter 1
    fcntl1.c: 00667: pa_t15: trace: path counter 4
    fcntl1.c: 00677: pa_t15: trace: path counter 5
    fcntl1.c: 00837: ch_t15: trace: path counter 6
    fcntl1.c: 00845: ch_t15: trace: path counter 7
    fcntl.c: 02605: fcn_to: trace: path counter 1
    fcntl.c: 02410: tstlk: trace: path counter 1
    fcntl.c: 02417: tstlk: trace: path counter 2
    fcntl.c: 02513: cmp_lcks: trace: path counter 1
    fcntl.c: 02421: tstlk: trace: path counter 3
    fcntl1.c: 00851: ch_t15: trace: path counter 8
    fcntl1.c: 00861: ch_t15: trace: path counter 9
    fcntl1.c: 00687: pa_t15: trace: path counter 6
    fcntl.c: 02605: fcn_to: trace: path counter 1
    fcntl1.c: 00696: pa_t15: trace: path counter 7
    fcntl1.c: 00706: pa_t15: trace: path counter 8
    fcntl1.c: 00872: ch_t15: trace: path counter 10
    fcntl1.c: 00879: ch_t15: trace: path counter 11
    fcntl.c: 02605: fcn_to: trace: path counter 1
    fcntl.c: 02410: tstlk: trace: path counter 1
    fcntl.c: 02417: tstlk: trace: path counter 2
    fcntl.c: 02508: cmp_lcks: Result: Test Failure, Status: f
    fcntl.c: 02510: cmp_lcks: Info: F_RDLCK not created/detected properly
    fcntl.c: 02528: cmp_lcks: Info: lock lengths differ: got 5 - expected 15
    fcntl.c: 02421: tstlk: trace: path check failed in function call

    To summarize, after the first call to fcntl(), the child saw a
    5-byte lock starting at byte 5, as expected. After the second
    call, the child saw a 10-byte lock starting at byte 5. After the
    third call, the child unexpectedly saw a 5-byte lock starting at
    byte 5. Upon further investigation, we have found that after the
    third call to fcntl(), there are two locks associated with the
    file, the 5-byte lock starting at byte 5 and the 10-byte lock
    starting at byte 10.

    - It is also interesting to note that test 15 fails on our
    implementation but test 11 is virtually identical and it succeeds.
    The difference between the tests is that test 11 uses F_SETLK and
    test 15 uses F_SETLKW. For some reason, these two ways to set
    locks work differently. After the third fcntl(F_SETLK) call, the
    child will see a 15-byte lock starting at byte 5.as expected.
    After the third fcntl(F_SETLKW) call, the child sees a 5-byte lock
    starting at byte 5. While this is indeed strange, the standards
    do not prevent F_SETLKW and F_SETLK from combining locks
    differently as long as the status of individual bytes is correct.
    Test Output
    /tset/POSIX.os/ioprim/fcntl/T.fcntl 15.Failed

    Test Description:
    For the XNFS specification:
    If the implementation supports file locking for files residing on
    a remote file system: On a call to fcntl(fildes, F_SETLKW, arg)
    when l_type = F_RDLCK is specified a shared lock is created on the
    segment specified in arg.
    For the XSH specification:
    On a call to fcntl(fildes, F_SETLKW, arg) when l_type = F_RDLCK is
    specified a shared lock is created on the segment specified in
    arg.
    Posix Ref: Component FCNTL Assertion 6.5.2.2-20(A)

    Test Strategy:
    OPEN pipes using opensync() - (genlib)
    OPEN new file using creat()
    WRITE 40 bytes to file
    CLOSE file and OPEN it again O_RDWR
    SEEK to offset 5 within the file
    CREATE process pair
    PARENT Process:
    SET lock {F_RDLCK, SEEK_SET, 5, 5, 0} using fcntl(F_SETLKW)
    WRITE data to pipe using sendsync() - (genlib)
    CHILD Process:
    READ data from pipe using waitsync() - (genlib)
    VERIFY that fcntl(F_GETLK) with lock description {F_WRLCK, SEEK_SET,
    5, 20, 0} gives lock description {F_RDLCK, SEEK_SET, 5, 5,
    getppid()}
    WRITE data to pipe using sendsync() - (genlib)
    PARENT Process:
    READ data from pipe using waitsync() - (genlib)
    SET lock {F_RDLCK, SEEK_SET, 10, 5, 0} using fcntl(F_SETLKW)
    WRITE data to pipe using sendsync() - (genlib)
    CHILD Process:
    READ data from pipe using waitsync() - (genlib)
    VERIFY that fcntl(F_GETLK) with lock description {F_WRLCK, SEEK_SET,
    5, 20, 0} gives lock description {F_RDLCK, SEEK_SET, 5, 10,
    getppid()}
    WRITE data to pipe using sendsync() - (genlib)
    PARENT Process:
    READ data from pipe using waitsync() - (genlib)
    SET lock {F_RDLCK, SEEK_SET, 10, 10, 0} using fcntl(F_SETLKW)
    WRITE data to pipe using sendsync() - (genlib)
    CHILD Process:
    READ data from pipe using waitsync() - (genlib)
    VERIFY that fcntl(F_GETLK) with lock description {F_WRLCK, SEEK_SET,
    5, 20, 0} gives lock description {F_RDLCK, SEEK_SET, 5, 15,
    getppid()}
    WRITE data to pipe using sendsync() - (genlib)
    PARENT Process:
    READ data from pipe using waitsync() - (genlib)
    SET lock {F_RDLCK, SEEK_SET, 5, 20, 0} using fcntl(F_SETLKW)
    WRITE data to pipe using sendsync() - (genlib)
    CHILD Process:
    READ data from pipe using waitsync() - (genlib)
    VERIFY that fcntl(F_GETLK) with lock description {F_WRLCK, SEEK_SET,
    5, 25, 0} gives lock description {F_RDLCK, SEEK_SET, 5, 20,
    getppid()}
    WRITE data to pipe using sendsync() - (genlib)
    PARENT Process:
    READ data from pipe using waitsync() - (genlib)
    SET lock {F_WRLCK, SEEK_SET, 20, 10, 0} using fcntl(F_SETLKW)
    WRITE data to pipe using sendsync() - (genlib)
    CHILD Process:
    READ data from pipe using waitsync() - (genlib)
    VERIFY that fcntl(F_GETLK) with lock description {F_WRLCK, SEEK_SET,
    5, 25, 0} gives lock description {F_RDLCK, SEEK_SET, 5, 15,
    getppid()}
    VERIFY that fcntl(F_GETLK) with lock description {F_RDLCK, SEEK_SET,
    20, 25, 0} gives lock description {F_WRLCK, SEEK_SET, 20, 10,
    getppid()}

    Test Information:
    F_RDLCK not created/detected properly
    lock lengths differ: got 5 - expected 15

    Review Information

    Review Type TSMA Review
    Start Date null
    Completed null
    Status Complete
    Review Recommendation No Resolution Given
    Review Response
    It is agreed that this is a test suite deficiency and it is recommended
    that a waiver is granted on these grounds.

    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:

     

    Back   

Contact the Certification Authority