[craig@jcb-sc.com: Re: BUG]

[craig at jcb-sc dot com]

[It occurred to me that this fuller explanation should be in the
egcs archives somewhere!]


------- Start of forwarded message -------
X-Coding-System: undecided-unix
Mail-from: From craig@jcb-sc.com Wed Jun 16 17:52:58 1999
Return-Path: <craig@jcb-sc.com>
Delivered-To: craig@localhost
Received: (qmail 14980 invoked from network); 16 Jun 1999 17:52:56 -0000
Received: from localhost (root@127.0.0.1)
  by localhost with SMTP; 16 Jun 1999 17:52:56 -0000
Received: from world.std.com
	by fetchmail-4.5.8 POP3
	for <craig/localhost> (single-drop); Wed, 16 Jun 1999 13:52:56 EDT
Received: from mescaline.gnu.org by world.std.com (TheWorld/Spike-2.0)
	id AA11350; Wed, 16 Jun 1999 12:44:40 -0400
Received: from europe.std.com (europe.std.com [199.172.62.20])
	by mescaline.gnu.org (8.9.1a/8.9.1) with ESMTP id MAA00678
	for <fortran@gnu.org>; Wed, 16 Jun 1999 12:44:36 -0400
From: craig@jcb-sc.com
Received: from world.std.com by europe.std.com (STD1.2/BZS-8-1.0)
	id MAA08140; Wed, 16 Jun 1999 12:44:32 -0400 (EDT)
Received: from world.std.com by world.std.com (TheWorld/Spike-2.0)
	id AA21673; Wed, 16 Jun 1999 11:56:41 -0400
Received: (qmail 20429 invoked by uid 500); 16 Jun 1999 15:37:49 -0000
Date: 16 Jun 1999 15:37:49 -0000
Message-Id: <19990616153749.20428.qmail@deer>
To: dmg@bell-labs.com
Cc: koenig@ifm.uni-hannover.de
Cc: fortran@gnu.org
Cc: craig@jcb-sc.com
In-Reply-To: <3760BE5C.EE36860D@ifm.uni-hannover.de> (message from Jens Koenig
	on Fri, 11 Jun 1999 09:44:28 +0200)
Subject: Re: BUG
References:  <3760BE5C.EE36860D@ifm.uni-hannover.de>
X-UIDL: 7864a38b627e4e117105b211255a76d0

Ian Watson has exposed a small bug in libI77, and I've modified his
fix slightly (eliminating an unneccessary line, plus modifying commentary
and whitespace to better suit libI77 conventions).  Here is the patch:


*** libf2c/libI77/backspace.c.~1~	Wed Jun 16 09:49:07 1999
- --- libf2c/libI77/backspace.c	Wed Jun 16 11:23:20 1999
*************** integer f_back(alist *a)
*** 25,28 ****
- --- 25,29 ----
  	if(b->uwrt) {
  		(void) t_runc(a);
+ 		f = b->ufd;	/* t_runc might change b->ufd */
  		if (f__nowreading(b))
  			err(a->aerr,errno,"backspace")


The comment is fairly self-explanatory.  The original test case is
enclosed below.

On the assumption that the patch is correct, and, due to the fact
that it does represent a regression (though a long-undiscovered one!)
in libI77 -- which I verified by trying the f2c/libf2c combination
that came with my Redhat Linux 5.2 system -- I'm going to put the
above patch into g77 0.5.25, aka gcc 2.95, aka egcs 1.2.

Please let me know ASAP if you think the above patch is wrong, i.e.
will make things worse than better!  (It does at least fix the
bug that was reported.  And it *looks* reasonable.)

Also, in Ian's original analysis, also enclosed below (after the
test case), he wondered about the reason apparently unrelated OPEN/CLOSE
might affect the bug's appearance.

I believe it's simply due to whether the C library returns the
same file descriptor as t_runc starts out with, when it reopens
the file.

If, prior to the file being backspaced being opened, another file is
opened, and then, before the backspace itself, that other file is
closed, there'll be a "free" file descriptor that the C library might
use for a new open call.

So if the C library returns a different file descriptor, so b->ufd
ends up different after the backspace, the bug shows up -- otherwise,
it doesn't.

I've looked into all other calls to t_runc, as well as
f__nowwriting, which also closes and opens the same file, and
they all seem to be kosher.

I've also reproduced the reported bug by using the latest f2c+libf2c
combination from netlib (as of earlier today), and tested out the
fix in that environment as well.  So, unless I screwed something
up in my setup, my own work shouldn't involve any g77 modifications
to libf2c at all (Ian's did, though, and I wanted to be sure I
isolated f2c from g77 in my verification of his work, which was
clearly quite helpful!).

        tq vm, (burley)


Original test case:
- --------
* Sender: koenig@ifmpc39.ifm.uni-hannover.de
* Date: Fri, 11 Jun 1999 09:44:28 +0200
* From: Jens Koenig <koenig@ifm.uni-hannover.de>
* To: fortran@gnu.org
* Subject: BUG
* Content-Type: text/plain; charset=us-ascii
* X-UIDL: f4d08ccff91abfe758ede05b01eaedd7
*
C Hello
C
C We have found the following bug of the GNU-FORTRAN compiler:
C
C After compiling the following statments with the GNU-Fortran
compilier, version 
C 0.5.24, every second programm-call fails with the following 
C message:
C
C           backspace: end of file
C           apparent state: unit 4 named aus2
C           lately writing sequential formatted external IO
C           Aborted
C
C  After a failing run the file "aus2" contains two times the word UNSINN
C  After a succesfull run the file "aus2" contains the words UNSINN and UNSINN2
C  If you delete the file "aus2" after any run the next programm-call will never
C  fail!
C
C  The statements:

      PROGRAM ERR_PC

      IMPLICIT NONE
C_______________________________________________________________________
C
      open(3,file='aus1')
      open(4,file='aus2')
      write (4,'(a6)') 'UNSINN'
      write (4,'(a6)') 'UNSINN'
      CLOSE(3)
      BACKSPACE 4
      write (4,'(a7)') 'UNSINN2'
      close (4)

      END

C
C A succesfull run is possible, if
C 
C - no action is performed with channel 3
C - move the statement open(3) behind the statement open(4)
C - move the statement close(3) behind the statement backspace(4)
C - replace the format-string of the third writing-statement on unit(4) with 
C   a format similar to the first/second string (a6)
C   e.g.  write(4,'(a6)') 'UNSIN2'

C
C The following actions have no affect on the behaviour of the programm
C
C - Changing the unit-numbers or use other numbers
C - removing the first and second write-statement

C We have seen the bug in theses systems:
C - OS: linux, kernel 2.0.36 (SUSE 6.0)
C   Fortran: 0.5.24
C   GCC: egcs-2.91.60 
C
C
C - OS: linux, kernel 2.0.36 (SUSE 6.0)
C  FORTRAN: 0.5.24
C   GCC: 2.7.2.3

C In the follwowing system, the programm works fine
C - OS: linux, kernel 2.0.33
C  FORTRAN: 0.5.19.1 
C  GCC: 2.7.2.1

* sincerly yours
* Jens
* 
* _________________________________________________________________________
* 
*    Dipl.-Ing. Jens Koenig         mailto:koenig@ifm.uni-hannover.de
*                                   Tel.: 0511/762-4122
*                                   Universitaet Hannover
*                                   IfM Institut fuer Mechanik
*                                   Appelstrasse 11
*                                   30167 Hannover
- --------

Ian's analysis:
- --------
Date: Sat, 12 Jun 1999 00:37:59 -0500
From: Ian A Watson <WATSON_IAN_A@Lilly.com>
Subject: BACKSPACE bug
To: fortran@gnu.org
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
X-Lotus-Fromdomain: LILLY
X-UIDL: 5ef37d4b3c10cd02d77b1967d5c7eeb8



Indeed nasty stuff in there.

I'm surprised at how libf2c does a truncate operation. It seems
to first copy the file to a temporary, close the original file,
reopen it, and then copy from the temporary back to the target
file. I'm sure there must be a good reason for this, but I cannot
imagine what it might be. On a large file, it could be horrible.

Anyway, I think the following patch will take care of things. The
problem was that t_runc, during the closing and reopening, was
changing the file pointers associated with file units. Unfortunately,
f_back had made a local copy of these variables, and when it
returned from t_runc, it was looking at old data - and since it
wasn't doing error checking at that stage, all this passed
un-noticed.

Still some definite mysteries here: why did opening a completely
different file unit in the programme avoid the problem? If it
wasn't so late, I'd try to figure that out, but I can offer no
explanation.

Definitely worth passing to the f2c maintainer in order to make
sure what I've suggested won't break other things - looks safe
to me (famous last words).

Note too that I did this with 2.8.1 rather than egcs. The reason
for this is that 2.8.1 compiles in the proper path names into
libg2c, whereas egcs compiles in relative paths, so gdb works
much better with 2.8.1 rather than egcs. Yes, this could be
solved with the -I option to gdb, but this was easier for me.
There appears to be only a minor change in the egcs version of
backspace.c. I'd like to suggest egcs changing back to the
gcc way of doing things in this respect.

To bed...

Ian

*** ../f/runtime/libI77/backspace.c      Sat Jun 12 00:15:01 1999
- --- g77-0.5.23/f/runtime/libI77/backspace.c   Fri May  1 14:19:42 1998
*************** integer f_back(alist *a)
*** 27,34 ****
     }
     if(b->uwrt) {
          (void) t_runc(a);
- -                 b = &f__units[a->aunit];   /* reload in case of change in
t_runc */
- -                 f = b->ufd;
          if (f__nowreading(b))
               err(a->aerr,errno,"backspace");
          }
- --- 27,32 ----
- --------
------- End of forwarded message -------