On Tue, Jun 25, 2002 at 03:53:25PM +0200, Maciej W. Rozycki wrote:
> On Tue, 25 Jun 2002, Carsten Langgaard wrote:
>
> > The next LTP failure line is:
> > pipe05 1 BROK : Unexpected signal 11 received.
> >
> > For this one I haven't got a fix, because the failure is due to the way
> > the pipe syscall is implemented for MIPS (so we need a fix in both the
> > kernel and glibc).
> >
> > The glibc code look like this
> > SYSCALL__ (pipe, 1)
> > /* Plop in the two descriptors. */
> > sw v0, 0(a0)
> > sw v1, 4(a0)
> >
> > /* Go out with a clean status. */
> > move v0, zero
> > j ra
> > .end __pipe
> >
> > The problem is that the code is called with $a0 = 0. So the 'sw v0,
> > 0(a0)' after the syscall generates a segmentation fault.
>
> The test is broken and it's what should be fixed, instead -- several
> Linux platforms do it this way, e.g. Alpha and IA-64. A SIGSEGV is a
> valid response for an invalid address. Remember you test pipe(3) and not
> pipe(2).
The question is what API spec is relevant for Linux. My pipe(2) man page
says (there is no pipe(3) man page):
int pipe(int filedes[2]);
...
ERRORS
...
EFAULT filedes is not valid.
whereas The Single UNIX ® Specification, Version 2
(http://www.opengroup.org/onlinepubs/007908799/xsh/pipe.html)
implies the SIGSEGV is OK.
Maybe the LTP folks can shed a light on this.
Regards,
Johannes
