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

The Open Brand -- Problem Reporting and Interpretations System

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

Report 1317 Actions

    Problem Report Number 1317
    Submitter's Classification Test Suite problem
    State Resolved
    Resolution Test Suite Deficiency (TSD)
    Problem Resolution ID TSD.X.0599
    Raised 1970-01-01 08:00
    Updated 2003-03-13 08:00
    Published 1998-04-01 08:00
    Product Standard Internationalised System Calls and Libraries Extended V2 (UNIX 98)
    Certification Program The Open Brand certification program
    Test Suite VSU version 5.0.2
    Test Identification CAPIbase/bsd_signal 3
    Problem Summary TSD4U.00219 This request claims the test FAILS improperly on IUTs which do not send parents a SIGCHLD signal when the child receives a SIGCONT signal.
    Problem Text
    This test will pass on our system, if VSU_MACHINE_PERFORMANCE is set to
    20, but the test take 50 minutes. We believe the test has some problems
    as noted below:

    The main loop is essentially doing the following:
    block SIGCHLD because kill(children[child], SIGSTOP) will generate a
    SIGCHLD signal for the parent (i.e. the child will send it as a response
    to being SIGSTOP'ed.
    send SIGSTOP to the child. This stops the child process and sends a SIGCHLD
    to the parent (who is blocking it until after the kill(SIGSTOP) returns.
    atomically unblock SIGCHLD *and* wait for any signal not being blocked.
    In this testcase, it will pretty much always get the SIGCHLD blocked.
    NOTE: once the signal is delivered, SIGCHLD is blocked once again.
    This is the first error this test makes.
    It should do 1 of 2 things:
    1) sighold(SIGCHLD) once for the parent process and never bother
    with it again......or
    2) after sigpause(SIGCHLD), do a sigrelse(SIGCHLD).
    The reason is that sigpause(SIGCHLD) only unblocks SIGCHLD for that
    invocation. Once it returns, the original mask is restored (i.e., the
    one set up by sigpause(SIGCHLD). Based on what this test does and
    why it does it, we would recommend using sighold(SIGCHLD) once in the
    parent and letting sigpause() catch the SIGCHLD after the kill().
    Otherwise, have to do: sighold(SIGCHLD);kill();sigpause(SIGCHLD);
    sigrelse(SIGCHLD)'

    That's the first part of the iteration. The second part is the one that's
    really wrong:

    It blocks SIGCHLD because it's going to call kill(children[child], SIGCONT).
    This is not necessary because, unlike SIGSTOP, SIGCONT doesn't make the
    child generate a SIGCHLD for the parent. Also, as pointed out above,
    SIGCHLD is still blocked anyway.
    send SIGCONT to the child. The child resumes execution. Note, it does
    *NOT* send a SIGCHLD (not supposed to) to the parent like SIGSTOP did.
    atomically unblock SIGCHLD *and* wait for any signal not being blocked.
    Again, in this testcase, it is really just waiting for the SIGCHLD,
    but unlike the SIGSTOP case above, it never arrives. This is a false
    assumption. So sigapuse(sigchld) (after the SIGCONT) will just hang
    forever! Except, we set up a 3 second alarm at the top of the loop,
    so when the alarm goes off, sigpause() finally gets a signal (though
    not what was intended), and the testing continues.

    So, the reason the testcase passes when left to run for 50 minutes is because
    the 3 second alarm is forcing it to chug along..., if not for this
    alarm, this test would never get past the first iteration.

    To fix the testcase, move sighold(SIGCHLD) out of the for loop. Put
    it right before the for loop begins.
    Then remove the other sighold(SIGCHLD) below as well as the 2nd
    sigpause(SIGCHLD) (after the "kill(children[child], SIGCONT)").

    Doing this, then recompiling and rerunning the test. It finishes almost
    immediately.

    Test Output
    TEST CASE: bsd_signal

    TEST PURPOSE #3
    After a successful call to void (*bsd_signal(int sig,
    void (*func)(int))) (int) when sig is SIGCHLD a
    SIGCHLD signal shall be generated for the calling
    process whenever any of its child processes stop.
    PREP: Start up children
    PREP: Set SIGCHLD interrupt handler
    TEST: SIGSTOP to random children produce SIGCHLD interrupts
    ERROR: Test took longer than 1200 seconds: presuming
    function is hung and terminating test
    3 FAIL

    Review Information

    Review Type TSMA Review
    Start Date null
    Completed null
    Status Complete
    Review Recommendation No Resolution Given
    Review Response
    We recommend this request be refused.

    The submitter makes 2 points above...

    1. We are calling sighold too many times...

    We agree with this but do not believe this does any damage. We
    believe it is legal to block the same signal as many times as you
    like. The redundant calls should be silently ignored.

    2. We are trapping SIGCHLD after a SIGCONT and the child does not
    send the parent a signal in this instance...

    The <signal.h> description has a table of the reasons a signal is generated.
    For SIGCHLD, the valid codes include (on page 798),

    CLD_CONTINUED stopped child has continued

    We believe the intent is clear that SIGCHLD is generated when a "stopped
    child has continued," and that the only process that can be notified
    is the parent of the child process.

    If the IUT raises SIGCHLD signals when a child receives a SIGCONT this
    test should PASS.

    Review Type SA Review
    Start Date null
    Completed null
    Status Complete
    Review Resolution No Resolution Given
    Review Conclusion
    This request should go for for a 14 day review.

    A possible interpretation of the specification is that
    SIGCHILD should only be generated when children stop,
    not when they start.

    Review Type Expert Group Review
    Start Date null
    Completed null
    Status Complete
    Review Resolution No Resolution Given
    Review Conclusion
    The Base Working group believe that the specification
    does not require SIGCHLD to be generated when a "stopped child
    has continued". There is a requirement for si_code to
    contain CLD_CONTINUED if SIGCHLD was received by the parent
    when a stopped child continued.

    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