Strange Seg fault from allocated array.

[burgel]

Hi, I'm using fortran 11.1 (088) on OSX 10.6 (using intel64 option) and have encountered a strange issue with array allocation. In a subroutine, an array is allocated:

allocate ( gd(-1:1,-1:1,-1:1,0:nnzt,2) )

(in this case nnzt=70 and is passed in the argument list. I tried hardwiring the value in the allocation statement with no change in results.)

I can then write to gd(-1,-1,-1,0,1), but writing to, say gd(-1,-1,-1,1,1) produces a seg fault. Also, "size" "lbound" and "ubound" report correct array dimensions. If the array is set up instead as automatic:

real gd(-1:1,-1:1,-1:1,0:nnzt,2)

Then there is no problem. Also setting -O0 -g -CB seems to allow the code to run, so it might be some kind of bad optimization. This code has worked fine with a number of compilers as well as previous versions of ifort.

There are plenty of other allocated multidimensional arrays elsewhere in the (extensive) code (a cloud simulation model). I tried to search the forum here but didn't easily find a similar issue.

Any ideas?

-- Ted

[Ron_Green]

did you find this article at the top of the forum?

http://software.intel.com/en-us/articles/determining-root-cause-of-sigsegv-or-sigbus-errors/

ron

[mecej4]

I cannot generate the reported error with this test code:

[fortran]program alloca
integer :: nnzt = 70
call sub(nnzt)
stop

contains

subroutine sub(nz)
integer :: nz
real, allocatable, dimension(:,:,:,:,:) :: gd
allocate(gd(-1:1,-1:1,-1:1,0:nz,2))
gd(-1,-1,-1,0,1) = -55
gd(-1,-1,-1,1,1) = +77
write(*,10)gd(-1,-1,-1,0,1),gd(-1,-1,-1,1,1)
10 format (1x,2E12.4)
return
end subroutine sub

end program alloca
[/fortran]

and version 11.1.072 on Linux-x64. Please furnish a short program to demonstrate the bug.

[burgel]

Yeah, I'm familiar with those common causes, which is why I'm so puzzled. The same code runs fine on OS 10.5 with ifort 10.1.021 (also 64-bit), which is why I wonder if it might be compiler issue. Of course, newer compiler versions sometimes reveal lurking problems in old code. I'll try 11.1 on the same platform to see if that reproduces the problem.

It's a pretty large total code, so reproducing with a test code might be difficult.

[burgel]

Actually, your little code can reproduce the bug (on OS 10.6) if it is split into two files (thanks!):

all1.f90:

program alloca

implicit none

integer :: nnzt = 70

call sub(nnzt)

stop

end program alloca

all2.f90:

subroutine sub(nz)

implicit none

integer :: nz

real, allocatable, dimension(:,:,:,:,:) :: gd

write(0,*) 'nz = ',nz

allocate(gd(-1:1,-1:1,-1:1,0:nz,2))

gd(-1,-1,-1,0,1) = -55

gd(-1,-1,-1,1,1) = +77

write(*,10)gd(-1,-1,-1,0,1),gd(-1,-1,-1,1,1)

10 format (1x,2E12.4)

return

end subroutine sub

Then compiled as

skylla% tar xzf alloc.tgz

skylla% ifort -O2 -c all1.f90

skylla% ifort -g -O2 -c all2.f90

skylla% ifort -o allo.exe all1.o all2.o

skylla:mansell% gdb allo.exe

[snip]

(gdb) run

Starting program: /Users/myaccount/allo.exe

Reading symbols for shared libraries ++. done

nz = 70

Program received signal EXC_BAD_ACCESS, Could not access memory.

Reason: 13 at address: 0x0000000000000000

0x0000000100000c47 in sub (nz=Cannot access memory at address 0x40

) at all2.f90:6

6 allocate(gd(-1:1,-1:1,-1:1,0:nz,2))

(gdb)

This generates no problems on 10.5.8, but seg faults on 10.6 (running 10.6.3 with either 11.1/076 or 11.1/088). So it looks like some interaction with Snow Leopard causing the problem??

-- Ted

[burgel]

Well, I tried it on a different 10.6 box, and it works fine. One difference I found is the ld versions are different:

On the machine that works:

skylla:tmp% ld -v

@(#)PROGRAM:ld PROJECT:ld64-95.2.12

llvm version 2.6svn, Apple Build #2207-05

(and gcc version is 4.2.1, Apple Build 5646)

On the machine that seg-faults:

spark:alltmp% ld -v

@(#)PROGRAM:ld PROJECT:ld64-97.2

llvm version 2.6svn, Apple Build #2207-05

(and gcc version is 4.2.1, Apple build 5659)

[mecej4]

Can you rule out the known X-code incompatibility, which is listed in a sticky entry for this forum?

http://software.intel.com/en-us/forums/showthread.php?t=73942&o=d&s=lr

[burgel]

The x-code incompatibility is probably it. The-use-asm workaround does work for the test code, too. Thanks!