Access violation from a combination of programming error, allocatable strings and certain compiler options

[Karanta__Antti]

Hi!

I have been investigating an access violation that only occurs in production build but not in debug build. I have been able to make quite a minimal example that reproduces the error.

Here's the code:

[fortran]module stringer

    implicit none

contains

    ! a devious routine that does not always allocate 
    ! the return value
    pure function create_string( actually_allocate ) result( res )
    
        logical, intent(in) :: actually_allocate
        character( len = : ), allocatable :: res
        
        if ( actually_allocate ) res = 'hello world'
    end function

    ! two crashing routines where runtime checks do no good.
    ! The difference is that in the first one an unallocated allocatable string
    ! is assigned to a local character buffer whereas in the second the
    ! unallocated string is passed to a routine that expects a character buffer
    
    subroutine crash
        character( len = 100 ) :: string
        
        
        string = create_string( actually_allocate = .true. )        
        call print_len( string )


        ! this will not go well...
        string = create_string( actually_allocate = .false. )
        call print_len( string )
    
    end subroutine
    
    subroutine crash2
        character( len = : ), allocatable :: string
        
        
        string = create_string( actually_allocate = .true. )
        call print_len( string )


        string = create_string( actually_allocate = .false. )
        ! this will not go well...
        call print_len( string )

    end subroutine

end module

program lentest

    use stringer

    implicit none
    
    call crash
    call crash2

end program

subroutine print_len( s )

    character( len = * ), intent(in) :: s

    print '(I10)', len( s )

end subroutine
[/fortran]

If you compile this e.g. like this:

ifort lentest.f90

there will be no problems, the program will run just fine.

OTOH, compiled with either of these will cause the program to end in access violation:

ifort /check:uninit /check:pointer /RTCu /traceback /check:bounds /O3 /Qopenmp /Qopt-prefetch4 lentest.f90

ifort /Qopenmp lentest.f90

Now, I know that there is an error in the program, although I'm not sure whether it is in the function create_string not always allocating it's return value or the caller not being prepared for the return value not being allocated. Is it legal for a function returning an allocatable string to leave the return value unallocated?

In either case, it would be immensely helpful if there was a runtime check that would notice this problem, print out an error message and quit the program. Maybe there already is one and I'm not aware of it? Any other hints?

Environment: Windows 7 64bit, ifort11.1.054, compiling 32 bit executable

[Steven_L_Intel1]

It's not illegal for the function to return an unallocated result but it is "illegal" to reference an unallocated value. I would have expected /check:pointer to pick up on this, but it doesn't. I will ask the developers to add this. Issue ID is DPD200175687.

The reason it works in a Release mode is most likely that the length field is zero when the lower level copy routine is called - just the way it happened to work out. When you get the error, the length is unpredictable.

[Karanta__Antti]

Thanks Steve!

Is it possible for me to subscribe to the said issue to follow its progress?

[Steven_L_Intel1]

Subscribe to this thread for updates.

[Steven_L_Intel1 · Accepted solution]

The compiler has been fixed to give an error under /check:pointer for this case. This will appear in a future release.