topic Re: ifort bug: large array inside BLOCK causes segementation fault in Intel® Fortran Compiler

ifort bug: large array inside BLOCK causes segementation fault

hsnyder — Mon, 30 Aug 2021 18:56:44 GMT

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

Re: ifort bug: large array inside BLOCK causes segementation fault

Steve_Lionel — Mon, 30 Aug 2021 19:10:13 GMT

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.

Re: ifort bug: large array inside BLOCK causes segementation fault

hsnyder — Mon, 30 Aug 2021 19:50:14 GMT

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).

Re: ifort bug: large array inside BLOCK causes segementation fault

Steve_Lionel — Mon, 30 Aug 2021 19:55:13 GMT

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.

Re: ifort bug: large array inside BLOCK causes segementation fault

Barbara_P_Intel — Mon, 30 Aug 2021 20:04:59 GMT

unlimit -all prints the default stack size on Linux as

stack size (kbytes, -s) 8192

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

Re: ifort bug: large array inside BLOCK causes segementation fault

hsnyder — Mon, 30 Aug 2021 21:33:35 GMT

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.

Re: ifort bug: large array inside BLOCK causes segementation fault

Steve_Lionel — Mon, 30 Aug 2021 21:35:50 GMT

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.

Re: ifort bug: large array inside BLOCK causes segementation fault

hsnyder — Mon, 30 Aug 2021 21:39:05 GMT

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

Re: ifort bug: large array inside BLOCK causes segementation fault

Ron_Green — Fri, 03 Sep 2021 21:55:38 GMT

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