Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.
28445 Discussions

Using INQUIRE( SIZE=) in a function leds to immediate termination

Arjen_Markus
Honored Contributor I
903 Views

Hello,

I am trying to implement a function getsize() to return the size of a file (*). When I use gfortran for this, it works fine, but using Intel Fortran 18 on either Windows or Linux the program crashes immediately. On Linux I see this stacktrace:

~/tmp/fortran> ifort stdlib_test.f90
~/tmp/fortran> ./a.out
Start
Size: -1
forrtl: severe (174): SIGSEGV, segmentation fault occurred
Image PC Routine Line Source
a.out 000000000040456D Unknown Unknown Unknown
libpthread-2.12.s 00007F6D526AE7E0 Unknown Unknown Unknown
a.out 0000000000420B01 Unknown Unknown Unknown
a.out 00000000004036A3 Unknown Unknown Unknown
a.out 000000000040349E Unknown Unknown Unknown
libc-2.12.so 00007F6D52329D1D __libc_start_main Unknown Unknown
a.out 00000000004033A9 Unknown Unknown Unknown

On Windows this is not shown, but the program simply stops.

Here is the program:

program stdlib_test

!use os_path

implicit none
integer :: unit
logical :: error

integer :: ierr
integer :: sz

character(len=:), allocatable, dimension(:) :: split_str
character(len=:), allocatable :: startdir

print*, "Start"

inquire( file = 'testtxt', size = sz, iostat = ierr )
print*, "Size: ", sz

print*, "local_getsize('test.txt'): ", local_getsize('test.txt')
!print*, "getsize('test.txt'): ", getsize('test.txt')
print*, "Done"

contains
function local_getsize(path)

!integer(int64) :: getsize
integer :: local_getsize
character(len=*), intent(in) :: path
integer :: ierr

!write(*,*) '>>', path
inquire( file = path, size = local_getsize, iostat = ierr )
if ( ierr /= 0 ) then
local_getsize = -1
endif
!write(*,*) '>>', getsize

end function local_getsize
end program stdlib_test

If I uncomment the write statement in the function, it works fine. Note that the INQUIRE statement in the main program works fine as well.

Is there any way I can get this to work?

(*) This is part of an effort to create a "standard library" - see https://fortran-lang.org/packages/libraries

0 Kudos
10 Replies
mecej4
Honored Contributor III
891 Views

Recursive I/O, such as the invocation of a function in an expression in an I/O list, when the function itself perfoms I/O to the same unit, can cause problems. I am not sure if such I/O is still forbidden by the standard, but Intel Fortran did have Error 40 for such errors. See also this post by Steve L.

Intel Fortran on Windows will give you a line number traceback if you compile with the /traceback compiler option.

You can overcome the problem by breaking up the PRINT statement as

sz=local_getsize('test.txt')
print*, "local_getsize('test.txt'): ", sz
0 Kudos
Arjen_Markus
Honored Contributor I
886 Views

You misunderstand the problem, I am afraid. If I do NOT include the write statement in the function, the program fails. I tried the /traceback option on Windows, but that did not give any useful information - the program simply stops without any output. When I do include the write statement, it works.

A suggestion I received was to open the file and inquire via the unit number, that does work. Not ideal, but better than the program simply stopping.

(My apologies for including the program code as plain text instead of code, by the way. I did not think of that possibililty)

0 Kudos
Arjen_Markus
Honored Contributor I
874 Views

Here is a program that DOES work with the simple implementation:

module sizes
    use iso_fortran_env, only: int64
private
public :: getsize
contains
integer(int64) function getsize( filename )
    character(len=*), intent(in) :: filename

    integer :: ierr

    inquire( file = 'testje.f90', size = getsize, iostat = ierr )
end function getsize
end module sizes

program chksize
    use sizes
    implicit none

    write(*,*) getsize('testje.f90')


end program chksize

 

I have no idea what makes this program behave so differently from the previous one. Mind you: I have tried a number of variants, with the implementation of getsize() in a separate module and in the same source file as the main program etc.

0 Kudos
MWind2
New Contributor III
857 Views

When I assign result of function local_getsize(path) to a variable and call the print with variable, it works fine. What would be fortran print function evaluation rules(or not)?

0 Kudos
Steve_Lionel
Honored Contributor III
852 Views

This is clearly a bug in the run-time library. The access violation appears within the call in the main program to transmit the function result value. (I did have to fix up "testtxt" in the initial INQUIRE and create the test.txt file). There's nothing wrong with doing the INQUIRE in the function. Please submit a bug report to Intel.

 

0 Kudos
MWind2
New Contributor III
842 Views

If I can assign to a variable sz=local_getsize('test.txt'), and print*, "local_getsize('test.txt'): ", sz, but cannot print*, "getsize('test.txt'): ", getsize('test.txt'), then would it not seem to be a problem with print statement implementation?

 

 

sz=local_getsize('test.txt')
print*, "local_getsize('test.txt'): ", sz !works
print*, "local_getsize('test.txt'): ", local_getsize('test.txt')! crashes

but then the following works

program testprint
    
    implicit none
    ! Variables
     integer :: ix
    ! Body of testprint
    ix = iresult(37)
    print *, ix
    print *, iresult(37)
    print *,'Done'
contains
    function iresult (iin)
    integer, intent(in)::iin
    integer :: iresult
      iresult = iin*2+iin/3
    end function iresult
    

    end program testprint

 

0 Kudos
Steve_Lionel
Honored Contributor III
825 Views

You have a test case - send it to Intel and let them figure out what went wrong. My guess (much of my career was working on Fortran I/O libraries) is that some internal state is not being set or restored correctly when the INQUIRE happens in the middle of another I/O statement.

Arjen_Markus
Honored Contributor I
798 Views

I may be completely overlooking it, but I cannot find the right webpage to report this - I do feel a bit awkward about that. Can you point in the right direction?

0 Kudos
Arjen_Markus
Honored Contributor I
787 Views

Thank you - I have submitted the problem report, support case 04834525

Reply