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

The Open Brand -- Problem Reporting and Interpretations System

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

Report 0285 Actions

    Problem Report Number 0285
    Submitter's Classification Specification problem
    State Resolved
    Resolution Permanent Interpretation (PIN)
    Problem Resolution ID PIN.X.0001
    Raised 1992-09-04 08:00
    Updated 2003-03-13 08:00
    Published 1992-09-24 08:00
    Product Standard Internationalised System Calls and Libraries (XPG4)
    Certification Program The Open Brand certification program
    Test Suite VSX4 version 4.2.3
    Test Identification POSIX.os/procprim/kill 13
    Specification System Interfaces and Headers Issue 4
    Location in Spec See Problem Text
    Problem Summary PIN4.001 The strategy used in the test has no basis in the normative standards and an error was reported thru the vsx support channel. The VSX developers have confirmed that this has been classified as a known...
    Problem Text

    The strategy used in the test has no basis in the normative standards and
    an error was reported thru the vsx support channel. The VSX developers have
    confirmed that this has been classified as a known problem and
    a new strategy will be used in a future release of VSX
    (see the VSX4.2.4beta update note).

    The problem is that part of the non-normative ISO POSIX.1 standard
    was inverted to assume normative behaviour of the kill() interface.
    This is being used as a basis for testing process and process group lifetime.

    The test itself expects the kill() to return zero and signal a success.
    There is also no basis for that. The rationale for the standard only says
    that ESRCH is inappropriate, but not which behaviour is appropriate.
    Since a ZOMBIE process is already a inactive process (according to the
    definition of process life time), signalling it makes no sense and an
    errno should be returned. Since the process is still visible in the
    process table, ESRCH may indeed be inappropriate. But what error code
    is appropriate? Since no standard specifies what errno must be returned,
    the test is not appropriate and should be removed.
    Test Output
    ************************************************************************
    /tset/POSIX.os/procprim/kill/T.kill 13 Failed

    Test Description:
    When the last process in process group pgrp has terminated but not
    been waited for, then a call to kill(gpgrp, 0) does not give an ESRCH
    error.
    This test is not executed in XPG3 mode.
    Posix Ref: Component KILL Assertion 3.3.2.2-XX(A)

    Test Strategy:
    CREATE process pair
    CHILD process:
    CREATE process session using setsid
    EXIT from the process using exit()
    PARENT process:
    SLEEP for WAITTIME/2 seconds
    CALL kill(-child, 0)
    VERIFY that kill() succeeds

    Test Information:
    kill(-child, 0) failed
    RETURN VALUES: expected: 0, observed: -1
    ERRNO VALUES: expected: 0 (NO ERROR), observed: 3 (ESRCH)
    ************************************************************************

    Review Information

    Review Type TSMA Review
    Start Date null
    Completed null
    Status Complete
    Review Recommendation No Resolution Given
    Review Response
    I must admit to having a degree of sympathy with the implementor in this
    case. Neither XPG 4 nor POSIX clearly identify whether this should be
    considered an error or considered a successful call. The hint in the
    POSIX.1 rationale that ESRCH is inappropriate could also be deduced from
    the description of the ESRCH error and the requirement that errors are only
    flagged for conditions associated with their meaning. The real problem with
    the ESRCH indication is that it suggests that it is unnecessary to make a call
    to wait() or waitpid() to release the resources associated with a terminated
    process or process group. This could cause unnecessary use of resources.

    As you point out, the assumption that the call to kill() should succeed, is
    incorrect. The test should allow kill() to fail and to indicate an error other
    than that specified in the XPG or to succeed. To this extent, I agree that
    the test is in error. However, the fact that the system produced -1 with
    an error indication of ESRCH, also suggests that the implementation is
    incorrect.

    With regard to application portability, I can see no reason why an application
    should be concerned about signalling zombie processes. An application can use
    waitpid() with the WNOHANG flag if it is uncertain as to the status of processes
    in a process group, there is no need to use kill() to determine this.

    With regard to the assertion, this is probably badly worded. It should say
    "then the process group lifetime is not ended" rather than "then a call to
    kill() does not give an ESRCH error".

    With regard to the test, it does not currently implement the assertion correctly
    though the implementation would still fail against a correct implementation
    of the current strategy.

    I suspect that the implementation correctly ends the process group lifetime
    at the point at which the zombie process is waited for and as such, the
    implementation conforms to the normative part of the standards. This would
    suggest that it is appropriate to grant a permanent waiver on the grounds
    that this is a grey area.

    However, I would suggest that the implementor also considers the use of a
    more appropriate error or by setting the error indicator to zero. My reason
    for suggesting this is that I expect the same problem to occur with other
    test suites and the resolution in those cases may not be the same as
    suggested here.

    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