HomeAbout Us A-Z IndexSearch * Contact Us Register LoginPress Shop

The Open Brand -- Problem Reporting and Interpretations System


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


Report 0521 Actions


    Problem Report Number 0521
    Submitter's Classification Test Suite problem
    State Resolved
    Resolution Rejected (REJ)
    Problem Resolution ID REJ.X.0140
    Raised 1997-07-28 08:00
    Updated 2003-03-13 08:00
    Published null
    Product Standard Internationalised System Calls and Libraries (XPG4)
    Certification Program The Open Brand certification program
    Test Suite VSX4 version 4.3.6
    Test Identification ANSI.os/streamio/putc 8,9
    Problem Summary PG4R.141 I believe that there is a timing problem with these test cases. The journal shows that the child terminated with a SIGPIPE. It appears that the test expects the SIGPIPE to be delivered before the putc...
    Problem Text
    I believe that there is a timing problem with these test cases.
    The journal shows that the child terminated with a SIGPIPE. It
    appears that the test expects the SIGPIPE to be delivered before
    the putc() returns.

    In trying to figure out the sequence of events, I ran putc{8} with
    a couple of different debug options and the test passed with certain
    options set.

    Other tests that fail for the same reason include:
    fputc 8,9
    putchar 8,9
    fflush 10,11
    fputs 8,9
    fwrite 14,15
    fprintf 65,66
    printf 65,66
    putc 8,9
    putchar 8,9
    puts 8,9
    vfprintf 65,66
    vprintf 65,66
    XOPEN.os/streamio/putw 8,9
    XPG4.os/wstreamio/fputws 8,9
    XPG4.os/wstreamio/putwc 10,11
    XPG4.os/wstreamio/putwchar 10,11
    POSIX.os/ioprim/write/T.write 23
    ANSI.os/genuts/abort/T.abort 2
    ANSI.os/genuts/exit/T.exit 2
    Test Output
    journal output:
    400|180 8 1 09:03:36|IC Start
    200|180 8 09:03:36|TP Start
    520|180 8 318767121 2 1|child process was terminated by signal 13 (SIGPIPE)
    520|180 8 318767121 2 2|deletion reason: fgets() failed to read data from pipe - errno 112(EAGAIN)
    220|180 8 2 09:03:36|UNRESOLVED
    410|180 8 1 09:03:36|IC End
    400|180 9 1 09:03:36|IC Start
    200|180 9 09:03:36|TP Start
    520|180 9 318767121 2 1|child process was terminated by signal 13 (SIGPIPE)
    520|180 9 318767121 2 2|deletion reason: fgets() failed to read data from pipe - errno 112(EAGAIN)
    220|180 9 2 09:03:36|UNRESOLVED
    410|180 9 1 09:03:37|IC End

    vrpt output:
    ************************************************************************
    /tset/ANSI.os/streamio/Mputc/T.putc 8 Unresolved

    Test Description:
    For the XNFS specification:
    Not in use.
    For the XSH specifcation:
    EPIPE in errno, a SIGPIPE signal and a return value of EOF when
    putc() attempts to write to a pipe that is not open for reading by
    any process.
    Posix Ref: Component PUTC Assertion 8.2.3.11-10(A)

    Test Information:
    child process was terminated by signal 13 (SIGPIPE)
    deletion reason: fgets() failed to read data from pipe - errno
    112(EAGAIN)
    ************************************************************************
    /tset/ANSI.os/streamio/Mputc/T.putc 9 Unresolved

    Test Description:
    For the XNFS specification:
    Not in use.
    For the XSH specifcation:
    EPIPE in errno, a SIGPIPE signal and a return value of EOF when
    putc() attempts to write to a FIFO that is not open for reading by
    any process.
    Posix Ref: Component PUTC Assertion 8.2.3.11-10(A)

    Test Information:
    child process was terminated by signal 13 (SIGPIPE)
    deletion reason: fgets() failed to read data from pipe - errno
    112(EAGAIN)
    ************************************************************************

    Review Information

    Review Type TSMA Review
    Start Date null
    Completed null
    Status Complete
    Review Recommendation No Resolution Given
    Review Response
    ./" Please note that I have taken the liberty of correcting some mistakes
    ./" in the list of of affected tests. (Removed sprintf, changed the names
    ./" of the XPG4.os tests).
    ./"
    This appears to be a case where some detail has been left out of POSIX.1
    but the omission has not been noticed because `everybody knows' that all
    systems behave a certain way. All that POSIX.1 has to say about delivery
    of SIGPIPE is in the description of the EPIPE error for write():

    "[EPIPE] An attempt is made to write to a pipe (or FIFO) that is not
    open for reading by any process. A SIGPIPE signal shall
    also be sent to the process."

    (The XPG4 text is the same but with "will" instead of "shall".)

    There is no explicit statement that the signal must be delivered before
    the write() call returns. However, this has always been the behaviour
    of traditional Unix systems, and the fact that the test suite expects
    it shows that all currently branded systems behave this way.

    Whilst there is no explicit statement about prompt delivery, equally
    there is no explicit warning to application writers that the signal
    could be delayed. If the intention were to allow the signal to be
    delayed then such a warning would be essential, as applications may
    need significant modification in order to allow for a delayed SIGPIPE.
    Consider, for example, a typical case where SIGPIPE is set to be ignored
    before a write operation to a particular pipe, and the old handler is
    restored afterwards. Instead of just checking for an EPIPE error in
    the normal way, in order to cope with a delayed SIGPIPE the code would
    have to be changed to catch the signal, and if the write produces an
    EPIPE error then wait for the signal to arrive (if it hasn't already)
    before restoring the old handler.

    There is undoubtedly a large amount of existing application code which
    would break, or at least be less robust, on an implementation which
    delays the SIGPIPE delivery (unless the delay is extremely short, i.e.
    not long enough for the SIGPIPE handling to be changed; note that the
    `streamio' test failures listed in this request each execute an alarm()
    call and a sigaction() call to change the SIGALRM handler before they
    change the SIGPIPE handler back to SIG_DFL, so this represents a very
    significant delay).

    It is recommended that this request be refused.

    Review Type SA Review
    Start Date null
    Completed null
    Status Complete
    Review Resolution Rejected (REJ)
    Review Conclusion
    This request is refused.

    Problem Reporting System Options:

     

    Back   


Contact the Certification Authority