Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.
Announcements
This community is designed for sharing of public information. Please do not share Intel or third-party confidential information here.
27241 Discussions

ifort bug: large array inside BLOCK causes segementation fault

hsnyder
Novice
733 Views

The following program causes a segmentation fault. If I reduce the size of the array `a` dramatically, it runs correctly - perhaps arrays created inside BLOCKs are being put on the stack? I believe this is a bug, but please let me know if I've misunderstood something.

program bug
block
real :: a(86400000)
a=10
print *, a(1)
end block
end program

 

I'm on Linux (Ubuntu 20.04, kernel 5.11.0-27-generic)

$ ifort --version
ifort (IFORT) 2021.3.0 20210609

0 Kudos
1 Solution
Steve_Lionel
Black Belt Retired Employee
714 Views

It's not a bug. A segfault is Linux' way of saying stack overflow. I am not sure if you can get a stack that big on Linux. Note that Linux does "lazy allocation" so it may not actually allocate the virtual memory until you touch it.

View solution in original post

8 Replies
Steve_Lionel
Black Belt Retired Employee
728 Views

Yes, it's being put on the stack, and you're getting a stack overflow. I suggest making it ALLOCATABLE instead and allocating it to the desired size.

hsnyder
Novice
719 Views

Thanks @Steve_Lionel - I've done as you suggest and it works. I still think it's a bug though - let's see if an Intel employee picks it up and reports it to the developers (I don't have a support subscription yet).

 

Steve_Lionel
Black Belt Retired Employee
715 Views

It's not a bug. A segfault is Linux' way of saying stack overflow. I am not sure if you can get a stack that big on Linux. Note that Linux does "lazy allocation" so it may not actually allocate the virtual memory until you touch it.

Barbara_P_Intel
Moderator
708 Views

unlimit -all prints the default stack size on Linux as 

stack size (kbytes, -s) 8192

That can be increased with ulimit -s <some number>.

 

 

 

hsnyder
Novice
692 Views

Right, I understand the segmentation fault, I was just confused about whether or not putting those arrays on the stack was "correct" (it felt surprising). If I understand @Steve_Lionel, then putting arrays declared in a block on the stack doesn't violate anything in the standard. In that case, I'll mark this topic as resolved - thanks very much for clarifying.

Steve_Lionel
Black Belt Retired Employee
683 Views

It's correct in two ways. First, variables declared in a block have a "scope" limited to that block. so when exiting the block the variable goes away. The stack is a natural way to do this. Second, in Fortran 2018 all procedures are recursive by default. Admittedly you just had a main program, but the overall default for local variables will be on the stack. (Earlier versions of Intel Fortran would default to static allocation for local arrays - but even so, an array in a block is not static.

hsnyder
Novice
680 Views

Ahhh, that makes sense, thanks very much for explaining.

Ron_Green
Moderator
594 Views

ulimit -s unlimited

Investigate linux shell limits, particularly stacksize

 

[rwgreen@orcsle127 u1310894]$ ifort -O0 -o stack stack.f90

[rwgreen@orcsle127 u1310894]$ ./stack

forrtl: severe (174): SIGSEGV, segmentation fault occurred

Image              PC                Routine            Line        Source             

stack              0000000000403A8A  Unknown               Unknown  Unknown

libpthread-2.28.s  00007FAC1BB23DC0  Unknown               Unknown  Unknown

stack              0000000000402B0B  Unknown               Unknown  Unknown

stack              0000000000402AE2  Unknown               Unknown  Unknown

libc-2.28.so       00007FAC1B771873  __libc_start_main     Unknown  Unknown

stack              00000000004029EE  Unknown               Unknown  Unknown

[rwgreen@orcsle127 u1310894]$ ulimit -a

core file size          (blocks, -c) unlimited

data seg size           (kbytes, -d) unlimited

scheduling priority             (-e) 0

file size               (blocks, -f) unlimited

pending signals                 (-i) 30179

max locked memory       (kbytes, -l) 16384

max memory size         (kbytes, -m) unlimited

open files                      (-n) 1024

pipe size            (512 bytes, -p) 8

POSIX message queues     (bytes, -q) 819200

real-time priority              (-r) 0

stack size              (kbytes, -s) 8192

cpu time               (seconds, -t) unlimited

max user processes              (-u) 30179

virtual memory          (kbytes, -v) unlimited

file locks                      (-x) unlimited

[rwgreen@orcsle127 u1310894]$

[rwgreen@orcsle127 u1310894]$ ulimit -s unlimited

[rwgreen@orcsle127 u1310894]$

[rwgreen@orcsle127 u1310894]$ ./stack

   10.00000    

 

 

Reply