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

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

Ritratto di 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.

    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

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

16 post / 0 new
Ultimo contenuto
Per informazioni complete sulle ottimizzazioni del compilatore, consultare l'Avviso sull'ottimizzazione
Ritratto di Steve Lionel (Intel)

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.

Steve
Ritratto di fortrandave

Steve,

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

Dave

Ritratto di 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

    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

Ritratto di sgeard@cad-schroer.co.uk

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

    character(len=132) :: citem

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.

Ritratto di Steve Lionel (Intel)

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.

Steve
Ritratto di 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

Ritratto di Steve Lionel (Intel)

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.

Steve
Ritratto di Steve Lionel (Intel)

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.

Steve
Ritratto di 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).

Linda
Ritratto di Steve Lionel (Intel)

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

Steve
Ritratto di Steve Lionel (Intel)

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.

Steve
Ritratto di fortrandave

Steve,

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

Dave 

Ritratto di Steve Lionel (Intel)

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

Steve
Ritratto di Steve Lionel (Intel)

The fix will be in Update 3.

Steve
Ritratto di Steve Lionel (Intel)

This is fixed in Update 3, available now.

Steve

Accedere per lasciare un commento.