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

The Open Brand -- Problem Reporting and Interpretations System

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

Report 1397 Actions

    Problem Report Number 1397
    Submitter's Classification Test Suite problem
    State Resolved
    Resolution Test Suite Deficiency (TSD)
    Problem Resolution ID TSD.X.0679
    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 CAPIbase/getutxent 1
    Problem Summary TSD4U.00136 This test may fail on implementations with 64 bit or shorter longs when the test is run after July 17, 1996.
    Problem Text
    Test cases: base/getutxent1, base/getutxent3
    base/getutxid2-13
    base/getutxline1 base/getutxline2
    base/pututxline1-3
    base/setutxent1

    The problem seems to be with the mk_utmpx.c program, subfunctions
    UtmpxKeyToUt_id and UtmpxKeyToUt_line. These functions stop working
    somewhere after mid-year 1996 on many implementations.
    The reason is that to generate a unique value of ut_id to use
    in database matches they first derive a key value from gettimeofday():

    gettimeofday((struct timeval *)&timeVal, (void *)NULL);
    UtmpxKey = timeVal.tv_sec;

    Then in UtmpxKeyToUt_id(), UtmpxKey is checked to make sure it is
    not less than 0 and then we see this line of code:

    utKey = (UtmpxKey * 100) + UtmpxRecordsGenerated;

    utKey is defined as a variable: long utKey;
    The problem is that UtmpxKey (The number of seconds since Jan 1, 1970)
    is an ever-increasing value. When that number is multiplied by
    100 (and UtmpxRecordsGenerated added to it) and stuffed into a
    long, there is a potential for overflow. On this year's earlier
    executions the test case succeeds but now the tv_sec value from
    gettimeofday() has grown so large that when multiplied by 100
    an overflow occurs and a negative number is generated and assigned
    to utKey. This has grave consequences for the rest of
    UtmpxKeyToUt_id(). The same scenario occurs in UtmpxKeyToUt_line().
    With a negative utKey value the following loop cannot even execute:

    while (utKey > 0)
    {
    z = utKey % 52; utKey = utKey / 52;
    /* 0,1,2,...25 = A,B,C,...Z ; 26,27,28,...52 = a,b,c,..
    ------------------------------------------------------------------------
    Since the journal is not very informative I put some "printf"
    statements into the mk_utmpx.c program in the aforementioned
    subroutine. I hand-calculated the tv_secs value returned by
    gettimeofday(), and the value is accurate.


    520|1 1 7733281 1 232|UtmpxKey is 838334010
    520|1 1 7733281 1 233|UtmpxKey is 838334010
    520|1 1 7733281 1 234|records generated 1
    520|1 1 7733281 1 235|The value of utKey is -2065944919

    The test cases all fail with "NOREPORT" because they wind up searching
    the database with a null ut_id string, iterating 25 times and then
    falling down an error leg that for some reason does not generate
    an "UNRESOLVED" failure code.
    Test Output
    10|1 /tset/CAPIbase/fgetutxent/fgetutxent1 11:30:07|TC Start, scenario r
    15|1 1.10 1|TCM Start
    400|1 1 1 11:30:08|IC Start
    200|1 1 11:30:08|TP Start
    520|1 1 19071041 1 1|SPEC1170TESTSUITE CASE 1
    520|1 1 19071041 1 2|A successful call to struct utmpx
    520|1 1 19071041 1 3|*getutxent(void) shall read the next entry from the
    520|1 1 19071041 1 4|user accounting database and return a pointer to a
    520|1 1 19071041 1 5|structure containing a copy of the entry.
    520|1 1 12058665 1 1|PREP: Find a unique ut_id for use by the test
    220|1 1 7 11:30:59|NORESULT
    410|1 1 1 11:30:59|IC End
    80|1 0 11:30:59|TC End
    900|11:30:59|TCC End

    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.

    The results above show what happens if the tests are run more
    than once without erasing the user accounting database. The
    first time the tests are run against a user accounting database
    invalid entry errors similar to the following may occur.

    SPEC1170TESTSUITE CASE 1
    A successful call to struct utmpx
    *getutxent(void) shall read the next entry from
    user accounting database and return a pointer to
    structure containing a copy of the entry.
    PREP: Find a unique ut_id for use by the test
    PREP: Compute the number of entries in the user
    PREP: Initialize a unique database entry
    PREP: rewind the database
    PREP: Write the entry to the database
    PREP: Initialize a unique database entry
    PREP: rewind the database
    PREP: Write the entry to the database
    PREP: Initialize a unique database entry
    PREP: rewind the database
    PREP: Write the entry to the database
    PREP: rewind the database
    PREP: Seek to the location in the utmp database
    the new entries should be
    TEST: getutxent() reads next entry from utmp database
    ERROR: Invalid entry obtained from the database
    Expected entry: Type=6 Timestamp=sec:839701007
    Id= User=VSU0 Pid=264306756 Li
    Got entry: Type=6 Timestamp=sec:839701008 msec
    Id= User=VSU0 Pid=264306756 Li
    FAIL

    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