- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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).
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
unlimit -all prints the default stack size on Linux as
stack size (kbytes, -s) 8192
That can be increased with ulimit -s <some number>.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Ahhh, that makes sense, thanks very much for explaining.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page