All of lore.kernel.org
 help / color / mirror / Atom feed
From: Richard Hirst <rhirst@linuxcare.com>
To: Alan Modra <alan@linuxcare.com.au>
Cc: parisc-linux@lists.parisc-linux.org
Subject: Re: [parisc-linux] Re: pipes
Date: Thu, 22 Feb 2001 11:00:54 +0000	[thread overview]
Message-ID: <20010222110054.A1129@linuxcare.com> (raw)
In-Reply-To: <Pine.LNX.4.21.0102221609360.14557-100000@front.linuxcare.com.au>; from alan@linuxcare.com.au on Thu, Feb 22, 2001 at 05:37:55PM +1100

Hi Alan,

On Thu, Feb 22, 2001 at 05:37:55PM +1100, Alan Modra wrote:
> 
> I had another look at the fixincludes problem, and found the following:
> 
> 14:36:08 write(5, "cd /scsi/tmp\nfile=sys/stat.h\nif ( test  -r types/vxTypesOld.h ) > /dev/null 2>&1\nthen echo TRUE\nelse echo FALSE\nfi\n\necho\necho ShElL-OuTpUt-HaS-bEeN-cOmPlEtEd\n", 158) = 158
> 14:36:08 alarm(10)                      = 0
> 14:36:08 read(6, "FALSE\n", 4096)       = 6
> 14:36:08 alarm(10)                      = 10
> 14:36:08 read(6, "FALSE\nShElL-OuTpUt-HaS-bEeN-cOmPlEtEd\n", 4096) = -512
> 14:36:18 --- SIGALRM (Alarm clock) ---
> 14:36:18 read(6, "FALSE\nShElL-OuTpUt-HaS-bEeN-cOmPlEtEd\n", 4096) = -512
> 14:36:28 --- SIGINT (Interrupt) ---
> 14:36:28 +++ killed by SIGINT +++
> 
> fd 5 and 6 are pipes to a /bin/sh.  -512 is ERESTARTSYS.  ERESTARTSYS
> shouldn't happen, and is why fixincludes is bombing.
> 
> Nothing suspicious in previous rt_sigaction calls as far as I could see,
> and putting in a debugging printk in do_sigaction shows sa_flags is being
> set correctly, to 0x40.
> 
> Ideas?

Simple test case:

main()
{
        char buf[10];

        strcpy(buf, "my buffer\n");
        alarm(1);
        read(0, buf, 10);
}


10:50:05 alarm(1)                       = 0
10:50:05 read(0, "my buffer\n", 10)     = -512
10:50:06 --- SIGALRM (Alarm clock) ---
10:50:06 +++ killed by SIGALRM +++


Looks like the primary problem is that your read is blocking for 10 seconds
thinking there is no data available.  Secondary problem is that the kernel
returns the wrong thing when the syscall is interrupted.

I gather there is something receiving the data written to fd 5, processing
it, and writing back up fd 6.  We want to know if that something writes
the missing data or not.

Richard

  parent reply	other threads:[~2001-02-22 11:00 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-02-09 15:29 [parisc-linux] pipes Alan Modra
2001-02-15 16:38 ` Richard Hirst
2001-02-22  6:37 ` [parisc-linux] pipes Alan Modra
2001-02-22 10:37   ` Jes Sorensen
2001-02-22 11:00   ` Richard Hirst [this message]
2001-02-22 11:09     ` Richard Hirst
2001-02-22 11:26       ` Alan Cox
2001-02-22 11:39         ` Alan Modra
2001-02-22 11:52           ` Alan Cox
2001-02-22 11:53           ` Richard Hirst
2001-02-22 11:34     ` Alan Modra
2001-02-22 11:52       ` Richard Hirst
2001-02-22 12:27         ` Alan Modra
2001-02-22 13:03           ` Richard Hirst
2001-02-22 13:27             ` Alan Modra
2001-02-22 17:00               ` Richard Hirst
2001-02-22 17:44                 ` Paul Bame
2001-02-23 12:25                   ` Richard Hirst
2001-02-23 12:43                     ` Alan Modra
     [not found] <20010223113052.G4660@linuxcare.com>
     [not found] ` <Pine.LNX.4.21.0102232231470.9345-100000@front.linuxcare.com.au>
2001-02-23 21:23   ` Richard Hirst
2001-02-26 17:57     ` Richard Hirst
2001-02-26 21:30       ` Matthew Wilcox

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20010222110054.A1129@linuxcare.com \
    --to=rhirst@linuxcare.com \
    --cc=alan@linuxcare.com.au \
    --cc=parisc-linux@lists.parisc-linux.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.