Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Arjen_Markus
Valued Contributor III
321 Views

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

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
Black Belt
309 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
Arjen_Markus
Valued Contributor III
304 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)

Arjen_Markus
Valued Contributor III
292 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.

MWind2
New Contributor I
275 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)?

Steve_Lionel
Black Belt Retired Employee
270 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.

 

MWind2
New Contributor I
260 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

 

Steve_Lionel
Black Belt Retired Employee
243 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
Valued Contributor III
216 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?

andrew_4619
Honored Contributor I
210 Views

Arjen_Markus
Valued Contributor III
205 Views

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

Reply