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

The Open Brand -- Problem Reporting and Interpretations System

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

Report 1624 Actions

    Problem Report Number 1624
    Submitter's Classification Specification problem
    State Resolved
    Resolution Permanent Interpretation (PIN)
    Problem Resolution ID PIN.X.0181
    Raised 1997-07-28 08:00
    Updated 2003-03-13 08:00
    Published 1997-10-10 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.12
    Test Identification CAPI.os/procprim/sigaction 30
    Specification System Interfaces and Libraries Issue 4 Version 2
    Location in Spec See Problem Text
    Problem Summary PIN4U.00047 This IR claims that SIGCHLD need not be generated when a stopped child has continued.
    Problem Text

    The way the test works is that a child is forked which stops itself.
    The parent sets up a handler for SIGCHLD, and sends the child
    SIGCONT. The parent expects the child to send SIGCHLD in response
    to reciept of SIGCONT. Thus the parent expects to enter the SIGCHLD
    signal handler, and in that signal handler have recieved a pointer to
    a siginfo structure such that the si_code field of that siginfo structure
    will equal CLD_CONTINUED.

    The problem is that I can find no indication in the relevant specs that
    indicates that a SIGCHLD is generated for the parent of a child in
    response to the child recieving SIGCONT. Certainly there is no mention
    of such behavior in the sigaction() description, which deals with SIGCHLD
    being generated for the parent of stopping children. Further, in the
    signal.h description, in the signal description, Xopen says that SIGCHLD
    is generated for stopped and terminated children - no mention about
    continued children. Lastly, although the siginfo part of signal.h
    mentions that a siginfo structure associated with SIGCHLD may contain
    the CLD_CONTINUED code, there is no mention about how such a siginfo
    may be arrived at, and in fact, contains wording to the effect that
    an implementation may not generate some of the values in the table.

    ADDITIONAL COMMENTS

    The waiver was refused because of text which requires CLD_CONTINUED
    code to be used when SIGCHLD is generated due to a stopped child being
    continued (see text below). From this, an unstated intent has been
    extrapolated that SIGCHLD is required to be generated when a stopped
    child is continued, and indeed this is the test that we are
    questioning.

    We do not believe this to be the intent and the text is
    clear that this is not the case. In the <signal.h>
    description (on page 798), the text is unequivocal when it states
    "Implementations may ... contain extensions or limitations that
    prevent some values from being generated". We believe that this
    statement is unambiguously stating that SIGCHLD/CLD_CONTINUED does not
    necessarily have to be generated and we can find no other text that
    requires it, the text only refers to the signal being generated when a
    child stops rather than continues.

    As the refusal was based on a perceived intent and the waiver request
    is based on explicit text, we request for the refusal to be reversed
    and the waiver granted.
    Test Output
    TEST PURPOSE #30
    After a call to int sigaction(int sig, const struct
    sigaction *act, struct sigaction *oact) with
    SA_SIGINFO set in the sa_flags member of the sigaction
    structure pointed to by act and sig equal to SIGCHLD,
    on entry to the signal catching function specified by
    the sa_sigaction member when the stopped child has
    continued the si_code member of the structure pointed
    to by the siginfo argument shall contain
    CLD_CONTINUED, the si_pid member shall contain the
    child process ID, the si_status member shall contain
    the child's signal and the si_uid member
    shall contain the real user ID of the process that
    sent the signal.
    PREP: Set up action for SIGCHLD
    PREP: fork() a child that stops itself
    PREP: Set up action for SIGCHLD
    TEST: Send SIGCONT to child
    PREP: Reset action for SIGCHLD in signal handler
    TEST: signal = SIGCHLD
    TEST: si_code = CLD_CONTINUED
    ERROR: si_code incorrect. Expected 6,Received 1
    TEST: si_status = SIGCONT
    ERROR: si_status incorrect. Expected SIGCONT,Received Unknown signal (0)
    30 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 sigaction() description (page 547) describes the SIGCHLD is
    generated when its child processes stop.

    If sig is SIGCHLD and the SA_NOCLDSTOP flag is not set in
    sa_flags, and the implementation supports the SIGCHLD signal,
    then a SIGCHLD signal will be generated for the calling
    process whenever any of its child processes stop. If sig is
    SIGCHLD and the SA_NOCLDSTOP flag is set in sa_flags, then the
    implementation will not generate a SIGCHLD signal in this way.

    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.

    Review Type Expert Group Review
    Start Date null
    Completed null
    Status Complete
    Review Resolution No Resolution Given
    Review Conclusion
    This is a grey area, the specification does not clearly
    state that SIGCONT generates a SIGCHLD signal.
    The working group recommends that a PIN be granted.

    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