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

The Open Brand -- Problem Reporting and Interpretations System

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

Report 1594 Actions

    Problem Report Number 1594
    Submitter's Classification Specification problem
    State Resolved
    Resolution Permanent Interpretation (PIN)
    Problem Resolution ID PIN.X.0151
    Raised 1995-12-10 08:00
    Updated 2003-03-13 08:00
    Published 1996-01-02 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 CAPI.os/mman/mmap 10,11
    Specification System Interfaces and Libraries Issue 4 Version 2
    Location in Spec See Problem Text
    Linked Problem Reports PG4C.000XXX, -, same, as, req.4.U.00163, (in
    Problem Summary PIN4U.00017 This test may fail because the portion of the spec the assertion based on has been ruled in error.
    Problem Text
    This test may fail because the portion of the spec the assertion
    based on has been ruled in error.

    The implementation under test fails these tests, that a partial
    page at the end of a mapped region is filled with 0s, and that
    any modifications there are not written back to file. Looking at
    the SVID and the POSIX 1003.1b-1993 specifications it would
    appear that the wording in the XSH4 V2 specification has been
    reworded incorrectly. A Base resolution was raised to address
    this matter. The X/Open Base Working Group Resolution 1170/127
    declares this part of the XSH4 V2 specification to be in error.
    The resolution is attached.

    Resolution Text:

    While using the VSU4 testsuite we found that we had a number of
    testsuite problems due to a gray area in the specification.

    fmmap10 and fmmap11 FAILs: Our implementation fails these tests,
    that a partial page at the end of a mapped region is filled with
    0s, and that any modifications there are not written back to
    file. We expect that any mmap implementation (at least on Intel
    architecture) would fail these tests: we have informally verified
    this. The tests are correctly testing against the Spec (page 399
    of of X/Open CAE Specification (1994) System Interfaces and
    Headers Issue 4, Version 2), but we query the Spec on this. The
    System V Interface Definition Third Edition Volume 1
    (mmap(KE_OS): page 12-6) says "The system will always zero-fill
    any partial page at the end of an object. Further, the system
    will never write out any modified portions of the last page of an
    object which are beyond its end"; the USL UNIX System V Release 4
    Programmer's Reference (mmap(2)) says the same, as does POSIX
    1003.1b-1993 (mmap(): page 238) (but substitutes "shall" for
    "will"). We have no problem with those Specs, but page 399 of
    the X/Open Spec says instead "The implementation always
    zero-fills any partial page at the end of a memory region.
    Further, the implementation never writes out any modified
    portions of the last page of a file that are beyond the end of
    the mapped portion of the file" i.e. whereas the other Specs are
    defining the behaviour of the partial page at end of "object"
    (file), the X/Open Spec is defining this behaviour for the
    partial page at end of "memory region" (mapping) - and making no
    specification for what happens at end of file. It would be
    possible (though wasteful of memory) to implement what the X/Open
    Spec asks in the case of MAP_PRIVATE mappings; but we do not see
    how in the case of MAP_SHARED mappings: there may be several
    concurrent such mappings of the same file, which must share
    modifications; yet the mappings may be of slightly different
    lengths, which the Spec demands be differently zero-filled, so
    those pages cannot be shared between the different mappings - so
    how can the modifications be shared? A similar problem arises
    with writing modifications beyond the mapped len. It seems that
    the writer of this part of the X/Open Spec wished to avoid the
    word "object", and mistakenly replaced it by "memory region" or
    "mapped portion of the file" instead of by "file". As they
    stand, the fmmap10 and fmmap11 tests should be withdrawn (any
    implementation which passes them is probably mishandling
    MAP_SHARED just to satisfy these tests); in due course they
    should be reinstated to test behaviour at end of file instead of
    at end of memory region.

    [Request text ends]

    [Resolution response]

    This appears to be a bug in the specification, the wording should
    have described behavior at the end of the "object" or "file".
    The test suite should be modified accordingly.
    Test Output
    400|76 10 1 06:28:43|IC Start
    200|76 1 06:28:44|TP Start
    520|76 1 20229 1 1|SPEC1170TESTSUITE CASE 10
    520|76 1 20229 1 2|A call to void *mmap(void *addr, size_t len, int prot,
    520|76 1 20229 1 3|int flags, int fildes, off_t off) shall perform
    520|76 1 20229 1 4|mapping operations on full pages and shall zero-fill any
    520|76 1 20229 1 5|partial page at the end of a memory region.
    520|76 1 20230 1 1|PREP: Obtain the system page size by call to
    520|76 1 20230 1 2| sysconf(_SC_PAGESIZE)
    520|76 1 20230 1 3|PREP: Establish signal handlers for SIGSEGV and SIGBUS
    520|76 1 20230 1 4|PREP: Allocate memory for buffer
    520|76 1 20230 1 5|PREP: Open a file
    520|76 1 20230 1 6|PREP: Write a page of data to file
    520|76 1 20230 1 7|PREP: Close and reopen the file
    520|76 1 20230 1 8|TEST: Map half of page from file
    520|76 1 20230 1 9|TEST: Mapped area padded to page boundary and zero filled
    520|76 1 20230 1 10|ERROR: Integer at offset 2048 in region = 512, expected = 0
    220|76 1 1 06:28:44|FAIL
    410|76 10 1 06:28:44|IC End
    80|76 0 06:28:44|TC End
    15|79 1.10 1|TCM Start
    400|79 11 1 06:28:51|IC Start
    200|79 1 06:28:51|TP Start
    520|79 1 20248 1 1|SPEC1170TESTSUITE CASE 11
    520|79 1 20248 1 2|The system shall not write out modified portions of
    520|79 1 20248 1 3|the last page of a file mapped by a call to void
    520|79 1 20248 1 4|*mmap(void *addr, size_t len, int prot, int flags, int
    520|79 1 20248 1 5|fildes, off_t off) which are beyond the end of the
    520|79 1 20248 1 6|mapped portion of the file.
    520|79 1 20249 1 1|PREP: Obtain the system page size by call to
    520|79 1 20249 1 2| sysconf(_SC_PAGESIZE)
    520|79 1 20249 1 3|PREP: Establish signal handlers for SIGSEGV and SIGBUS
    520|79 1 20249 1 4|PREP: Allocate memory for buffer
    520|79 1 20249 1 5|PREP: Open a file
    520|79 1 20249 1 6|PREP: Write a page of data to the file
    520|79 1 20249 1 7|TEST: Map in half of the page
    520|79 1 20249 1 8|PREP: Fill second half of mapped page with -1
    520|79 1 20249 1 9|PREP: Close & unmap file
    520|79 1 20249 1 10|PREP: Open and read file
    520|79 1 20249 1 11|TEST: Data beyond mapped half page not written to file
    520|79 1 20249 1 12|ERROR: Expected integer at offset 2048 = 512, is = -1
    220|79 1 1 06:28:52|FAIL
    410|79 11 1 06:28:52|IC End
    80|79 0 06:28:52|TC End

    Review Information

    Review Type TSMA Review
    Start Date null
    Completed null
    Status Complete
    Review Recommendation No Resolution Given
    Review Response
    A permanent interpretation is recommended.

    Review Type SA Review
    Start Date null
    Completed null
    Status Complete
    Review Resolution Permanent Interpretation (PIN)
    Review Conclusion
    A Permanent Interpretation is granted.

    Problem Reporting System Options:

     

    Back   

Contact the Certification Authority