An upgrade breaks input redirection

[Pete Wyckoff]

bill at Princeton.EDU wrote on Thu, 15 Jul 2004 09:38 -0400:
> Here are the strace outputs from the script.
> 
> The first one calls "mpiexec strace ./a.out <inp" while the second one 
> just calls "strace ./a.out <inp"
> 
> I'm not really sure what I should be looking at here though.

Look for the the lines where it stats the stdin file descriptor.

without:
    fstat64(0, {st_mode=S_IFREG|0664, st_size=19, ...}) = 0
    ioctl(0, SNDCTL_TMR_TIMEBASE, 0xbfffda84) = -1 ENOTTY
    brk(0x80cf000)                          = 0x80cf000
    read(0, "1 2 3 1.1 2.2 3.3\n\n", 134)   = 19
    lseek(0, -1, SEEK_CUR)                  = 18

with:
    fstat64(0, {st_mode=S_IFSOCK|0777, st_size=0, ...}) = 0
    ioctl(0, SNDCTL_TMR_TIMEBASE, 0xbfffddc4) = -1 EINVAL
    brk(0x80ce000)                          = 0x80ce000
    read(0, "1 2 3 1.1 2.2 3.3\n\n", 134)   = 19
    lseek(0, -1, SEEK_CUR)                  = -1 ESPIPE

Note that the Intel compiler Fortran runtime library seems to be
statting stdin and finds a regular file in the "without" case, but
finds a socket in the "with" case.  Nevertheless it tries to seek
backwards one byte for both, which is not a valid thing to do on
a socket.

Another test you can do is:
    cat inp | strace -o pipe ./a.out

For me, this one looks like:
    14018 fstat64(0, {st_mode=S_IFIFO|0600, ...}) = 0
    14018 read(0, "1", 1)                   = 1
    14018 read(0, " ", 1)                   = 1
    14018 read(0, "2", 1)                   = 1
    14018 read(0, " ", 1)                   = 1
    14018 read(0, "3", 1)                   = 1
    ...
and it reads one byte at a time intsead of in a chunk because it must
have understood that seeking back one byte on a fifo (pipe) is also
not a valid operation.

If you want to abstract mpiexec out of this to complain to intel,
try something like this:
    cat inp | rsh localhost strace -o $(pwd)/socket $(pwd)/a.out

I get S_IFSOCK and one-byte-at-a-time reads, but hopefully your
compiler will cause this to fail, just like in the mpiexec case.

Incidentally if you get rid of the extra '\n' on the end of your input
file, it doesn't try to seek back one byte and all may work then too.
Not that this is a proper fix.

		-- Pete