Another scratch-file bug

[egdorf at zaphod dot lanl dot gov (Skip Egdorf)]

> >Your patch mentioned above seems to be suspiciously similar to what I am
> >seeing. Could you send me some more details on what the problem was with
> >rewind and scratch files? Any other hints on where I should look??
> 
> I'm not sure, but I *think* this problem might have already been found
> and fixed for gcc 2.95, aka egcs 1.2, which should be released very
> soon (maybe around this weekend).  If you want to try a prerelease
> (snapshot or CVS-readonly checkout), or need other info on EGCS, see:
> 
>   <http://egcs.cygnus.com/>
> 
> Also, I have a little g77 web page at <http://world.std.com/~burley/g77.html>.
> 
>         tq vm, (burley)
> 

Well, I have it boiled out of my 100K-line legacy Fortran code, and the bug
is still in the current (june 28) egcs release.

I have fetched the egcs-19990629 version. It and glibc-2.1.1 are fresh-built
from sources on my RedHat-6.0 Linux box for debugging. I have removed the
RedHat compilers and libraries from the system, and this egcs and glibc are
now the sytstem defaults. By the way, this egcs seems to work fine for building
the kernel (2.2.10) and the glibc stuff.

The following program dumps core on both Linux and Solaris with g77 later than
0.5.21 or so. I will include info from the Linux box as it was my debugging
platform. The unit=39 and the extra backpace and rewind are there only because
this is the sequence in the old large legacy code. The "endfile" is the culprit.

This is the "test1.F" file compiled below.
---
      program main
      character*5 buf
 10   format (1x,a5)
c
      open (unit=39,status='scratch')
      write (39,10) 'line1'
      write (39,10) 'line2'
c
      backspace 39
      endfile 39
      rewind 39
c
      do 100 i = 1, 2
         read (39,10) buf
         write (*,*) buf
 100     continue
      stop
      end
---
System information and build is (although it also happens on Solaris...)
---
dilbert% uname -a
Linux dilbert.lanl.gov 2.2.10 #1 Wed Jul 7 13:30:18 MDT 1999 i586 unknown
dilbert% g77 -g -o test1 test1.F
dilbert% ./test1
fmt: end of file
apparent state: unit 39 named /tmp/fort.AopL42
last format: (1X,A5)
lately reading sequential formatted external IO
Abort (core dumped)
dilbert%
dilbert% g77 --version
GNU Fortran 0.5.25 19990628 (prerelease)
Copyright (C) 1997 Free Software Foundation, Inc.
For more version information on components of the GNU Fortran
compilation system, especially useful when reporting bugs,
type the command `g77 --verbose'.

GNU Fortran comes with NO WARRANTY, to the extent permitted by law.
You may redistribute copies of GNU Fortran
under the terms of the GNU General Public License.
For more information about these matters, see the file named COPYING
or type the command `info -f g77 Copying'.
dilbert%
---

The iot() happens at the first "read". There is plenty of stuff in the
FILE *'s buffer, but the _IO_NO_READS flag has been turned on in the
struct FILE._flags word for unit 39. (check bit 0x4 of
f__units[39]->ufd->_flags)

Following through with gdb, the culpret seems to be the "endfile" statement.

The open works correctly with the fopen on line 251 of libI77/open.c
using mode "r+w" as it should. A "scratch" file can be both written and read.
f__units[39]->ufd->_flags has bits 0x06 zeroed...

In endfile.c, down at line 101 in t_runc(), the file is freopened() with
a mode of "w" only. <-- this is the error. The "read"ability of the file gets
lost. f__units[39]->ufd->_flags has bit 0x04 turned on.

Thus, when the read happens, the getc returns -1 with errno set to EBADF, because
the _flags word of the FILE structure has bit 0x04 turned on (_IO_NO_READS)
which is translated into EOF in fmt.c line 474. (The place in glibc-2.1.1 is
in _IO_new_file_underflow() line 349 in libio/fileops.c  called from getc
if anyone cares to dig that deep, but all that is proper, I think, given that
the file is opened for writting only...)

The problem is clearly that the system should remember that the scratch file
is open for "r+w" when it re-opens it in the endfile. I think I see the path
through the code, and I understand why the tempfile/copy stuff is going on
(endfile may have been done on a rewound - half-way-through file and so a
truncate must be done if we are on a seekable file... right?)

However, I don't really have enough of a grasp on how all the other pieces
fit together to suggest a proper fix. Suggestions on what else I should do are
welcome...

					Skip Egdorf
					hwe@lanl.gov