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

The Open Brand -- Problem Reporting and Interpretations System

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

Report 2566 Actions

    Problem Report Number 2566
    Submitter's Classification Test Suite problem
    State Resolved
    Resolution Rejected (REJ)
    Problem Resolution ID REJ.X.0686
    Raised 2011-03-16 03:31
    Updated 2011-06-01 10:49
    Published 2011-06-01 10:49
    Product Standard Internationalised System Calls and Libraries Extended V3 (UNIX 03)
    Certification Program The Open Brand certification program
    Test Suite VSX5 version 5.3.2
    Test Identification /tset/ANSI.os/locale/setlocale/T.setlocale 4-12,14
    and many more tests.
    Specification Base Definitions Issue 6
    Location in Spec N/A
    Problem Summary Problem appears to be caused by the tet_putenv() function (source code
    is TET3.6/src/tet3/dtet2lib/putenv.c). It changes "environ" in such way
    that our putenv(3c) cannot manage thus causing 100+ tests to SIGSEGV and
    core dump.
    Problem Text The tet_putenv() expands environ array, and put new variable in the end.
    It allocates (number of current env) + 2 entries, so the next call to
    tet_putenv() won't induce malloc(), thus address of "environ" won't
    change at the next call.

    libc's getenv()/putenv() first checks to see if env variables were
    changed without using system interfaces (putenv/setenv etc). The
    method to do this is simple; whether or not the "environ" points
    different address. It doesn't fully check the contents of array.

    Therefore, as far as "environ" points same address, getenv()/putenv()
    assumes that contents of array() weren't changed. They also count the
    number of env variables(environ_size, including NULL terminate), and
    assumes that the environ_size is valid as long as "environ" points same
    address.

    So what happens is, tet_putenv() was initially called and allocated
    environ array with 1 extra space left. getenv() was then called and it
    counted number of env variables (environ_size). Here, tet_putenv() was
    called again, and added one env variable onto the extra space.
    So, the actual number of env is no longer in sync with environ_size.

    Here, putenv() was called again, putenv() allocate space for new env,
    and copies old array by environ_size. As mentioned, environ_size is
    the number of entires including the last NULL. If environ_size was
    correct, putenv() copies all entries including the last NULL. If
    actual number was larger than environ_size, putenv() copies array
    partially which doesn't include NULL. So the terminating NULL is lost
    in this case which caused segv at the next call to those env related
    functions.

    I think that tet_putenv() shouldn't directly change environ, but
    should call library function (putenv()).

    A workaround solution was implemented and stopped all the tests from
    core dumping:

    /*
    ** tet_putenv() - add an environment string to the environment
    **
    ** return 0 if successful or -1 on error
    **
    ** this routine is here because not all systems have putenv(3)
    */

    TET_IMPORT int tet_putenv(s)
    char *s;
    {

    return (putenv(s));
    #if 0
    ...
    /* original code */
    ...
    #endif
    }

    However, a real preprocessor could be added to make this change
    work for Solaris and yet still have other platforms that do not
    have putenv() to use this code.

    #ifdef USE_TET_PUTENV
    ...
    /* original code */
    #else
    return putenv(...);
    #endif

    Of course the -DUSE_TET_PUTENV would have to be provided in the Makefile
    for platforms that do not have putenv(). Solaris would
    not use the preprocessor.

    In addition, all test code use putenv as well so it would make
    sense to do this to be consistent and in alignment with the tests
    as well.

    Suggestion: Make the same change in vsc lib as well.

    ===
    Part of Test Identification...
    ===

    All below are SIGSEGV failures:

    /tset/ANSI.os/locale/setlocale/T.setlocale 4-12,14
    /tset/CAPI.os/streams/fdetach/T.fdetach 7
    /tset/CAPI.os/time/getdate/T.getdate 7,16,17,25,26,29
    /tset/CAPI.os/xcurses/Mborder/T.border 3-9
    /tset/CAPI.os/xcurses/Mborder_se/T.border_se 2-9
    /tset/CAPI.os/xcurses/Mbox/T.box 1-3
    /tset/CAPI.os/xcurses/Mbox_set/T.box_set 1-3
    and many more xcurses functions...

    /tset/LFS.os/ioprim/dup/T.dup 1
    /tset/LFS.os/ioprim/dup2/T.dup2 1
    /tset/LFS.os/ioprim/fcntl/T.fcntl 1
    /tset/LFS.os/ioprim/write/T.write 1,4
    /tset/LFS.os/procprim/exec/T.execl 1
    /tset/LFS.os/procprim/exec/T.execle 1
    and more LFS.os tests.
    Test Output One example:

    /tset/ANSI.os/genuts/system_X/T.system_X 45 (unexpected system() return
    code)

    Review Information

    Review Type TSMA Review
    Start Date 2011-03-16 03:31
    Last Updated 2011-03-16 10:12
    Completed 2011-03-16 10:12
    Status Complete
    Review Recommendation Rejected (REJ)
    Review Response There are too many failures here to be able to grant a TSD.

    A patch for the TET harness will be issued.

    Review Type SA Review
    Start Date 2011-03-16 18:12
    Last Updated 2011-03-16 10:25
    Completed 2011-03-16 10:25
    Status Complete
    Review Resolution Rejected (REJ)
    Review Conclusion This request is rejected as there are too many failures here to be able
    to grant a TSD.

    A patch for the TET harness will be issued.

    Problem Reporting System Options:

     

    Back   

Contact the Certification Authority