Bug 35699 - [4.3/4.4 regression] run-time abort writing zero sized section to direct access file
Summary: [4.3/4.4 regression] run-time abort writing zero sized section to direct acce...
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: fortran (show other bugs)
Version: 4.4.0
: P4 normal
Target Milestone: 4.3.1
Assignee: Jerry DeLisle
URL:
Keywords: wrong-code
Depends on:
Blocks:
 
Reported: 2008-03-25 21:31 UTC by Dick Hendrickson
Modified: 2008-03-29 01:11 UTC (History)
3 users (show)

See Also:
Host:
Target:
Build:
Known to work: 4.1.3 4.2.1
Known to fail: 4.3.0 4.4.0
Last reconfirmed: 2008-03-26 00:58:02


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Dick Hendrickson 2008-03-25 21:31:07 UTC
On Windows XP, with SP2, the following program beeps at me
and opens an alert box saying
"a.exe has encountered a problem and needs to close.  
We are sorry for the inconvenience."

and offers to send Microsoft an error report (I declined).

Based on the print statements, it's the write statement that 
is causing the problem.

Changing the zero sized section subscripts from nf4:nf3 to
4:3 does not cure the problem 

      program try_qi0010
! fails on Windows XP
! gcc version 4.4.0 20080312 (experimental) [trunk revision 133139]



      call       QI0010 (  10,   1,   2,   3,   4,  9,   2)
      end

      SUBROUTINE QI0010 (nf10, nf1, nf2, nf3, nf4,nf9, np2)
      CHARACTER(9) BDA(nf10)
      CHARACTER(9) BDA1(nf10), bval

      INTEGER  J_LEN
      bda1(1) = 'x'
      do I = 2,10
      bda1(i) = 'x'//bda1(i-1)
      enddo
      bda = 'unread'

      print *, 'begin inquire'
      INQUIRE(IOLENGTH = J_LEN) BDA1(NF1:NF10:NF2), BDA1(NF4:NF3),
     $                               BDA1(NF2:NF10:NF2)

      print *, 'begin open '
      OPEN (UNIT=48,
     $      STATUS='SCRATCH',
     $      ACCESS='DIRECT',
     $      RECL = j_len,
     $      IOSTAT = ISTAT,
     $      FORM='UNFORMATTED',
     $      ACTION='READWRITE')

      print *, 'begin write '
      WRITE (48,IOSTAT = ISTAT, REC = 3) BDA1(NF1:NF10:NF2),
     $                    BDA1(NF4:NF3), BDA1(NF2:NF10:NF2)
      IF ( ISTAT .NE. 0) then
        print *, istat, ' WRITE FAILED '
        stop
      ENDIF
      ISTAT = -314

      print *, 'begin read '

      READ (48,IOSTAT = ISTAT, REC = NP2+1) BDA(NF1:NF9:NF2),
     $                       BDA(NF4:NF3), BDA(NF2:NF10:NF2)
      IF ( ISTAT .NE. 0) THEN
        print *, istat, ' read FAILED '
        stop
      ENDIF

      print *, 'begin check '
      DO J1 = 1,10
      BVAL = BDA1(J1)
      IF (BDA(J1) .NE. BVAL)
     $ print *, j1 ,BDA(J1),BVAL
  100 ENDDO;
      END SUBROUTINE
Comment 1 Dick Hendrickson 2008-03-25 21:49:50 UTC
I have another essentially identical subroutine that uses double complex instead of character and appears to fail in the same way.  I also have three other subroutines that write/read zero sized arrays and return a non-zero iostat value or incorrectly read a single value into the zero sized array.  These are simpler write/reads and only have a single array, as opposed to three, in the i/o lists.  For me, it's a mechanical pain in the rear to extract the additional cases.  I'm looking for advice, is it easier A) for you to send me a link to an experimental windows compiler once you think you have a fix, B) me to wait until the next release and then retry the other cases, C)  slowly over the next few days extract the others and make a working version of them?  Or, do you guys have another suggestion?

Dick Hendrickson

Dick Hendrickson
Comment 2 Dominique d'Humieres 2008-03-25 22:05:25 UTC
On (powerpc|i686)-apple-darwin9, I get a bus error at runtime:

 begin inquire
 begin open 
 begin write 
Bus error

Comment 3 Tobias Burnus 2008-03-25 23:16:17 UTC
Thanks for the report!

This is actually a regression; Jerry, do you have an idea?

valgrind shows:
==18956== Invalid write of size 1
==18956==    at 0x4C26A68: memset (in /usr/lib64/valgrind/amd64-linux/vgpreload_memcheck.so)
==18956==    by 0x4ED8002: write_buf (transfer.c:645)
==18956==    by 0x4ED8049: unformatted_write (transfer.c:769)
==18956==    by 0x401585: qi0010_ (jf.f:36)
==18956==    by 0x400D94: MAIN__ (jf.f:7)
==18956==    by 0x401BCB: main (fmain.c:21)
Comment 4 Jerry DeLisle 2008-03-26 00:58:02 UTC
No Idea, but I will investigate.
Comment 5 Jerry DeLisle 2008-03-26 05:16:49 UTC
This regression was caused by my patch for PR34876.  I am not sure it is really a regression since we were not handling zero sized arrays correctly before.  Regardless, I have isolated the problem and I am working on a solution.
Comment 6 Jerry DeLisle 2008-03-27 05:45:52 UTC
A patch has been submitted to fortran@gcc.gnu.org for approval.

http://gcc.gnu.org/ml/fortran/2008-03/msg00212.html
Comment 7 Dominique d'Humieres 2008-03-27 11:11:31 UTC
Works as advertised without regression on i686-apple-darwin9 for 32 and 64 bit modes.

Thanks for the patch.

Comment 8 Jerry DeLisle 2008-03-28 22:14:05 UTC
Subject: Bug 35699

Author: jvdelisle
Date: Fri Mar 28 22:13:17 2008
New Revision: 133699

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=133699
Log:
2008-03-28  Jerry DeLisle  <jvdelisle@gcc.gnu.org>

	PR libfortran/35699
	* io/transfer.c (write_buf):  Don't pad the record, just return if the
	data is NULL.  (next_record_w): If there are bytes left in the record
	for unformatted direct I/O, pad out the record with zero bytes.

Modified:
    trunk/libgfortran/ChangeLog
    trunk/libgfortran/io/transfer.c

Comment 9 Jerry DeLisle 2008-03-28 22:17:15 UTC
Subject: Bug 35699

Author: jvdelisle
Date: Fri Mar 28 22:16:29 2008
New Revision: 133700

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=133700
Log:
2008-03-28  Jerry DeLisle  <jvdelisle@gcc.gnu.org>

	PR fortran/35699
	* gfortran.dg/direct_io_10.f: New test.

Added:
    trunk/gcc/testsuite/gfortran.dg/direct_io_10.f
Modified:
    trunk/gcc/testsuite/ChangeLog

Comment 10 Jerry DeLisle 2008-03-28 23:24:19 UTC
Subject: Bug 35699

Author: jvdelisle
Date: Fri Mar 28 23:23:34 2008
New Revision: 133703

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=133703
Log:
2008-03-28  Jerry DeLisle  <jvdelisle@gcc.gnu.org>

	PR libfortran/35699
	* io/transfer.c (write_buf):  Don't pad the record, just return if the
	data is NULL.  (next_record_w): If there are bytes left in the record
	for unformatted direct I/O, pad out the record with zero bytes.

2008-03-28  Jerry DeLisle  <jvdelisle@gcc.gnu.org>

	PR fortran/35699
	* gfortran.dg/direct_io_10.f: New test.

Added:
    branches/gcc-4_3-branch/gcc/testsuite/gfortran.dg/direct_io_10.f
Modified:
    branches/gcc-4_3-branch/gcc/testsuite/ChangeLog
    branches/gcc-4_3-branch/libgfortran/ChangeLog
    branches/gcc-4_3-branch/libgfortran/io/transfer.c

Comment 11 Jerry DeLisle 2008-03-29 01:11:43 UTC
Fixed on trunk and 4.3.1