1.3.43: reading from /proc/self/fd/xx never gets EOF?

1.3.43: reading from /proc/self/fd/xx never gets EOF?

Post by Jonathan Kame » Thu, 23 Nov 1995 04:00:00



Until tonight, I was running 1.2.13.  I just upgraded to 1.3.43, and my lpd
filter stopped working.  It's a perl script which opens this command with
open():

/usr/bin/dvips -f -q < dvi-temp-1948 | /usr/bin/gs -dSAFER -dNOPAUSE -q
-sDEVICE=hl630 -sOutputFile=/proc/self/fd/5 - 5>&1 1>/dev/null 2>/dev/null|

And then reads from it using sysread() repeatedly until sysread() returns
undef (indicating EOF).  (Yes, there really is a reason for all that
file-descriptor frobbing.  Don't worry about it; that's not the point here.)

This worked fine under 1.2.13.  Under 1.3.43, however, the perl script hangs
in sysread() after the last block of data is read.

I managed to duplicate this with the following shell command:

bash$ dd if=/etc/termcap of=/proc/self/fd/1 bs=10 count=1 2>/dev/null | cat

On my system, this prints "# /etc/ter" and then hangs until I ^C it.  Removing
the "of=/proc/self/fd/1" makes it stop*.

I don't know if this problem is new in 1.3.43; like I said, I jumped straight
from 1.2.13 to 1.3.43.

Anybody know what's going on here?  Known bug?  Should I report it to Linus?

Thanks.

 
 
 

1.3.43: reading from /proc/self/fd/xx never gets EOF?

Post by Andries Brouw » Fri, 24 Nov 1995 04:00:00


...
: I managed to duplicate this with the following shell command:

: bash$ dd if=/etc/termcap of=/proc/self/fd/1 bs=10 count=1 2>/dev/null | cat

: On my system, this prints "# /etc/ter" and then hangs until I ^C it.

Yes, a bug in 1.3.43.  The problem is that the following comment
is incorrect. Deleting the comment and making a few other small
changes fixes the bug (but the comment would still be incorrect).

diff -r ../linux-1.3.43/linux/fs/pipe.c linux/fs/pipe.c
243,246d242
< /*
<  * Ok, these three routines NOW keep track of readers/writers,
<  * Linus previously did it with inode->i_count checking.
<  */
265a262,268

Quote:> static int pipe_rdwr_open(struct inode * inode, struct file * filp)
> {
>    PIPE_READERS(*inode)++;
>    PIPE_WRITERS(*inode)++;
>    return 0;
> }

356c359
<    NULL,           /* no special open code */
---
Quote:>    pipe_rdwr_open,


 
 
 

1.3.43: reading from /proc/self/fd/xx never gets EOF?

Post by Piercarlo Gran » Mon, 27 Nov 1995 04:00:00



Jonathan> [ ... /proc/fd is broken and dvips is less useful because of
Jonathan> it ... ]

Andries> Yes, a bug in 1.3.43.  The problem is that the following
Andries> comment is incorrect. Deleting the comment and making a few
Andries> other small changes fixes the bug (but the comment would still
Andries> be incorrect).

Ah thanks! It is actually older than 1.3.43, and it was on my list of
things to find out -- for it is necessary to get around another bug in
dvilj (for which I know the solution, BTW), that '-' as argument for
stdin does not work.

 
 
 

1. NO ppp0->ppp4 devices under Linux 1.3.43 or 1.3.45

I recently upgraded my kernel from 1.3.40 to 1.3.43 (and even tried
1.3.45), but NONE of the ppp devices shows up (when booting with the new
kernels - Ie. in /proc/net/dev the only thing that shows up is eth0 and
lo, no ppp0 through ppp4 like there used to be).

I tried compiling the kernel with CONFIG_PPP set to yes and also tried
compiling with CONFIG_PPP set to module and then loading the modules. Under
both cases I never saw the PPP devices show up and every time I tried to
use PPP got the error message: Sorry PPP is not available on this
system.

Btw, I am running ppp-2.2.0c, which I understand to be the latest
version (and a requirement for post 1.3.40 kernels).

Anyone know what is going on?

Bernie

2. /dev/tty1: Operation not permitted

3. ibcs2 with kernel 1.3.43

4. XFree86 & S3Trio64V+ won't do 16bpp@100Hz

5. Kernel Change Summary: 1.3.43

6. Apache WEB Server veryslow on 2.5 x86

7. Patch for 1.3.43?

8. problem with linux select

9. 1.3.43 Kernal and routing problems

10. Bug in 1.3.43

11. 1.3.43 fixed arp bug in 1.3.42, almost.

12. nice/renice don't work with 1.3.43 -- what's up?

13. 1.3.43 IDE access locks the machine up