Access violation while using Intel(R) Composer XE 2013 Update 2 (package 149)

[fortrandave]

Greetings,

I've recently started testing Intel(R) Composer XE 2013 Update 2 (package 149) and now my code generates an access violation when running in the debugger.  (The error is listed as a segmentation fault outside the debugger.)  My code executed ok when compiled with Intel(R) Composer XE 2011 Update 4 (package 196).

I'm looking for any input as to what may have changed between these two compiler releases and suggestions for what to do next.  The error is very strange to me.  Here are some code fragments.  It's hard to make a sample program that reproduces the problem since deleting seemingly unrelated code makes things change.
[fortran]
    character :: line*132

    outer: do

        write(*,*)'line',line
        continue
        write(*,*)'trimline',trim(line)
        continue

! Deleted code here for example purposes.

        do kk = 1, num_locs
            cloc = citem(line)
!cycle outer
            select case(trim(cloc))
            case('*')
                continue
                exit

! Additional deleted code
[/fortran]
On the second pass through the above subroutine code, an access violation is generated at the first write statement.  The exit statement at the end of the code snippet is effectively cycling the outer loop -- "enddo outer" is right after the case statement.  How can this be?  Why should one way of cycling the loop work and another, seemingly equivalent way not?  Why would deleting unrelated code matter?

Thanks,
Dave

[Steven_L_Intel1]

Sorry, you'll have to supply us with a test case that reproduces the problem. It is highly likely that the source of the problem is in code you haven't shown, and "what may have changed" is just a bit too broad a question, and not one likely to be helpful to you, especially when you're talking about releases about two years apart.

[fortrandave]

Steve,

Ok, thanks.  I'll work harder at coming up with an example.

Dave

[fortrandave]

I've created an example (included inline below and attached for convenience).  The example crashes when compiled with Composer XE 2013 Update 2 (package 149)  but works fine with Composer XE 2011 Update 4 (package 196).  Any help is appreciated!

Thanks,
Dave

[fortran]
    module example_m
    implicit none
    contains
!******************************************************************************
    integer function c2int(cvar)
    character(len=*), intent(in) :: cvar
    c2int = 0
    end function c2int    
!******************************************************************************
    function citem(line)
    character(len=*), intent(inout) :: line
    character(len=len(line)) :: citem
    integer :: i, len_trim_line, len_line

    len_trim_line = len_trim(line)
    len_line      = len(line)

    do i = 1, len_trim_line
        if(line(i:i) .eq. ',')exit
    enddo

    citem = ''
    if(i .ne. 1)citem = adjustl(line(1:i-1))
    if(i .gt. len_trim(line))i = len_trim(line)

    line(:i) = ''
    line = adjustl(line)

    end function citem
!******************************************************************************
    subroutine cskip(line, num)
    implicit none

    character(len=*), intent(inout) :: line
    character(len=len(line)) :: skip
    integer, optional, intent(in) :: num

    integer :: i, items

    items = 1
    if(present(num))items = num

    do i = 1, items
        skip = citem(line)
    enddo

    end subroutine cskip    
    end module example_m
!******************************************************************************
    program main
    use example_m
    implicit none

    integer :: k=0, kk, iloc, icfg
    character :: line*132, cloc*3

    outer: do

        continue
        line = '*'
        k    = k + 1

        do kk = 1, 172
            write(*,*)kk
            cloc = '*'
            select case(trim(cloc))
            case('*')
                continue
                exit
            case default
                iloc = c2int(cloc)
                icfg = c2int(citem(line))
                continue
            endselect

        enddo

    enddo outer

    end program main
[/fortran]

[Simon_Geard]

The problem is with the declaration of citem. If you replace your declaration with

[fortran]

    character(len=132) :: citem
[/fortran]

Then you'll find the program works. I'll leave the why to someone else, but I did try your original code with cygwin/gfortran and it didn't crash.

[Steven_L_Intel1]

Seems to be a stack overflow situation, but I'm still working to understand it. I don't see a problem in your code so far.

[fortrandave]

Steve,

Thanks for looking into this.  Note that if you comment out the lines in the case default -- lines that will never be executed -- the crash goes away.

Dave

[Steven_L_Intel1]

Yes, the appearance in the code of the call to cline, whether or not it is executed, seems to be the key. It worked in 12.1.5 but not in 13.0.0. Seems to be stack corruption going on - I will dig a bit more and then escalate to the developers.

[Steven_L_Intel1]

This is a strange one. The underlying error is that when the compiled code decides it wants to take the '*' case and exit the loop, instead of going to the end of the loop it jumps instead to a couple of instructions that are the tail end of the DEFAULT case. These are part of a stack save/restore sequence but the "save" part was never done so it ends up storing an uninitialized value into the stack pointer register.  Hilarity ensues.

The 12.1 compiler (Composer XE 2011) handled this fine, but 13.0 and later did not. I have escalated it to the developers as issue DPD200241319. I could not find any plausible workaround. Some changes appear to work, but just move the problem around. I will update this thread with any news.

[lklawrie]

This sounds very similar to my issue #687473 that never has been resolved.  I was told to not have that condition in the input file (which is hard to do when you're supporting users).

[Steven_L_Intel1]

Linda, why, yes it does seem similar.  Thanks for the reference.

[Steven_L_Intel1]

We've identified a fix for this problem, and I verified that it fixes it for both Dave's and Linda's programs. We're trying to get it in for Update 3 but timing may be tight. It shows up when a CYCLE or EXIT is done in a nested SELECT CASE - where it can be nested inside another SELECT CASE or a DO.

[fortrandave]

Steve,

Thanks for the quick work -- that's a relief!  Do you know the planned dates for Updates 3 and 4?

Dave 

[Steven_L_Intel1]

Update 3 is planned for the end of March. I think the fix will make that.

[Steven_L_Intel1]

The fix will be in Update 3.

[Steven_L_Intel1]

This is fixed in Update 3, available now.