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

The Open Brand -- Problem Reporting and Interpretations System

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

Report 1679 Actions

    Problem Report Number 1679
    Submitter's Classification Test Suite problem
    State Resolved
    Resolution Rejected (REJ)
    Problem Resolution ID REJ.X.0483
    Raised 2002-12-02 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 VSU version 5.1.2
    Test Identification CAPI.os/procenv/setrlimit 21
    Problem Summary PG4U.00186 The system did not set the SIGSEGV disposition to SIG_DFL before generating the signal.
    Problem Text
    The problem here is that when the process died, its stack pointer had leap-frogged the
    red zone set up by the kernel precisely to catch such stack
    overruns.

    This is the process's address map at death:

    core 'core' of 10138: ./setrlimit21
    00010000 64K r-x--
    0002E000 24K rwx--
    00034000 40K rwx-- [ heap ]
    FF280000 672K r-x-- /usr/lib/libc.so.1
    FF338000 24K rwx-- /usr/lib/libc.so.1
    FF33E000 8K rwx-- /usr/lib/libc.so.1
    FF380000 16K r-x-- /usr/platform/sun4u/lib/libc_psr.so.1
    FF3A0000 8K r-x-- /usr/lib/libdl.so.1
    FF3B0000 8K rwx--
    FF3C0000 160K r-x-- /usr/lib/ld.so.1
    FF3F8000 8K rwx-- /usr/lib/ld.so.1
    FF400000 8192K rwx-- [ stack ]
    total 9224K

    These are the process's stack pointer and frame pointer,
    as reported by 'mdb core':

    %sp = 0xff3f9c50
    %fp = 0xff3fbcb0

    %sp lies inside the R/W mapping for ld.so.1 with 944 bytes
    left before encountering the red zone above it.

    > 0xff3f9c50-FF3F8000=D
    7248
    > 0t8192-0t7248=D
    944

    So the kernel is able to build a stack frame insize ld.so.1's
    writable data at %sp and call the process's signal handler.

    The reason the stack pointer managed to leap-frog the red zone
    is a combination of how the test is constructed and how this
    hardware's register windows work. This is the function used to run
    the process out of stack (on purpose):

    static void
    recursive_fn(void)
    {
    volatile int array1[1024];
    volatile int array2[1024];

    array1_ref = array1; /* so compiler cannot discard storage */
    array2_ref = array2;
    recursive_fn();
    return;
    }

    Note that no stack variables are touched in the function.
    All that happens is thet their addresses are taken and stored
    in global variables.

    Because no part of the stack is touched during each recursion,
    the register windows allow the recursion to continue about
    four levels beyond where it should have stopped due to taking
    a memory fault. By that time, the stack pointer had entered
    ld.so.1's valid data space.

    Had this not happened, the test would have passed (with a core dump),
    as expected.

    The best fix is to make recursive_fn() actually touch at least
    one of its automatic variables:

    static void
    recursive_fn(void)
    {
    volatile int array1[1024];
    volatile int array2[1024];

    array1_ref = array1; /* so compiler cannot discard storage */
    array2_ref = array2;
    array1[0] = 0; /* actually touch the stack */
    array2[0] = 0;
    recursive_fn();
    return;
    }

    Another would be to reduce the size of the stack frame allocated
    by recursive_fn(). This would reduce the size of the leaps and
    allow the kernel to detect that the stack was overrun. Just
    eliminate the second array:

    static void
    recursive_fn(void)
    {
    volatile int array1[1024];

    array1_ref = array1; /* so compiler cannot discard storage */
    recursive_fn();
    return;
    }

    Test Output
    /tset/CAPI.os/procenv/setrlimit/T.setrlimit 21 Failed

    Test Description:
    Base Conditional Conformance
    If the implementation does not inhibit enforcement of limits for the
    resource RLIMIT_STACK:
    When the size of the stack for the calling process exceeds the limit
    set by a call to int setrlimit(int resource, const struct rlimit *rlp)
    for resource RLIMIT_STACK and the process is blocking or ignoring
    SIGSEGV, or is catching SIGSEGV and has not made arrangements to use
    an alternate stack, the disposition of SIGSEGV shall be set to SIG_DFL
    before it is generated.

    Test Information:
    PREP: Obtain the current stack limits
    TEST: Set limits with setrlimit
    INFO: Raise succeeded
    PREP: Set up a signal handler for SIGSEGV
    TEST: The signal disposition was set to SIG_DFL
    before delivery
    ERROR: SIGSEGV received, should have terminated process

    Review Information

    Review Type TSMA Review
    Start Date null
    Completed null
    Status Complete
    Review Recommendation No Resolution Given
    Review Response
    Apparently the system detected that the stack size limit had been
    exceeded, and accordingly generated a SIGSEGV (which is reported in
    the test output). However, as a side effect of the way this system
    detects that the limit has been exceeded and the way the test
    happens to arrange for it to be exceeded, the SIGSEGV signal was
    handled by calling the function installed as the signal handler for
    SIGSEGV, instead of the process being terminated by the SIGSEGV as
    the test expects.

    The specification states, in the description of RLIMIT_STACK on
    the getrlimit() page:

    If [...] the process is ignoring or catching SIGSEGV and has not
    made arrangements to use an alternate stack, the disposition of
    SIGSEGV will be set to SIG_DFL before it is generated.

    Since the system has not set the disposition to SIG_DFL before
    generating the SIGSEGV, the system's behaviour clearly does not meet
    the requirements of the specification.

    It is recommended that this request is 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