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

The Open Brand -- Problem Reporting and Interpretations System

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

Report 1396 Actions

    Problem Report Number 1396
    Submitter's Classification Test Suite problem
    State Resolved
    Resolution Test Suite Deficiency (TSD)
    Problem Resolution ID TSD.X.0678
    Raised 1970-01-01 08:00
    Updated 2003-03-13 08:00
    Published 1996-07-31 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/munmap 3
    Problem Summary TSD4U.00137 This test may fail on implementations if munmap'ed memory is allocated by the fork call before the bad memory reference is made.
    Problem Text
    This testcase verifies that
    "References to unmapped pages after a successful call
    to int munmap(void *addr, size_t len) and before any
    subsequent mapping of the unmapped pages shall result
    in the delivery of a SIGSEGV or a SIGBUS signal to the process."

    using the following logic:
    mmap() the memory
    munmap() that same memory location
    fork a child
    reference the unmapped memory in the child
    Verify that the child exits due to a SIGSEGV or SIGBUS

    However, there is a fundamental flaw in the logic of this testcase -
    specifically the assumption that forking a child will not use
    the memory which which has been unmapped.

    In the parent after the munmap() call successfully completes,
    our implementation frees the memory location and makes it available
    for reuse. When the test suite FORK macro is run it needs some
    memory. It allocates memory, and the memory which is allocated
    is the memory which was unmapped! Therefore when the memory
    location is referenced from the child it is a perfectly valid
    reference and does not produce a SIGSEGV or SIGBUS signal. The
    child exits normally.

    I have verified that our implementation does generate the SIGSEGV
    signal correctly when the unmapped memory is referenced by writing
    my own testcase and the same algorithm.... However since my code
    ran outside of the VSU test harness, the VSU macros FORK/EFORK
    were not used to fork the child, but rather the system interface
    fork(). The call to fork() did not allocate the memory which was
    unmapped and the reference to this memory location in the child
    did indeed generate a protection exception and a SIGSEGV as required.

    A better alternative would be to reference the memory from the parent
    and have a signal handler set up to verify that the correct signal
    is generated, which would be a more portable way to test this
    behaviour.
    Test Output
    TEST CASE: munmap

    TEST PURPOSE #3
    References to unmapped pages after a successful call
    to int munmap(void *addr, size_t len) and before any
    subsequent mapping of the unmapped pages shall result
    in the delivery of a SIGSEGV or a SIGBUS signal to the process.
    PREP: Obtain the system page size by call to
    sysconf(_SC_PAGESIZE)
    PREP: Open a file and initialize it
    PREP: Allocate memory for buffer
    PREP: Now set proper permissions and re-open file
    PREP: Map in the file
    TEST: Successful call to munmap returns 0
    TEST: SIGSEGV or SIGBUS when reference is made after unmap
    contents of *addr = 0
    ERROR: Expected process to terminate with signal, status is 0
    3 FAIL

    Review Information

    Review Type TSMA Review
    Start Date null
    Completed null
    Status Complete
    Review Recommendation No Resolution Given
    Review Response
    We agree this is a test suite deficiency in the test
    suite version(s) listed.

    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