$ gfortran --version GNU Fortran (Ubuntu 4.3.3-5ubuntu4) 4.3.3 ... $ cat crash.f90 program crash_random_number implicit none integer, parameter :: dp = kind(1.0d0) integer, parameter :: size = 100000000 real(kind=dp), dimension(size) :: x, y ! call random_seed() ! doesn't seem to change anything ! if I have only this statement, it seems to succeed call random_number(x) ! with this one present, the process is killed _immediately_ call random_number(y) end program crash_random_number $ gfortran -o crash_random_number -std=f95 -Wall -O0 crash.f90 $ ./crash_random_number Killed $ _Any_ of the following changes seems to let the program succeed on my machine: * changing the real type to default real * changing the array size from 100000000 (1e8) to 10000000 (1e7) * commenting out the second call to random_number; however, if the second call is present, as above, the program crashes immediately The default integer size is 4 bytes with maximum 2147483647 (2.147483647e9), so 1e8 fits into the integer range.
You use too much memory and your operating system kills your program for that. Read on ulimit(8).
Richard, thanks for the quick answer. :-) I hadn't gotten the idea of the limits because I can, from the same shell, allocate three lists with Python which have the same size (1e8) and contain floating point values of the same precision (i. e. 8-byte floats), and in addition some memory overhead for each number. Inspecting limits with bash's ulimit and settings in /etc/security/limits.conf doesn't seem to imply any size/memory limits either. Running the Fortran program under valgrind gives: valgrind: mmap(0x804b000, 1600000000) failed in UME with error 22 (Invalid argument). valgrind: this can be caused by executables with very large text, data or bss segments. Taking valgrind's message into account, it's probably reasonable to check mmap's return value and give a more helpful error message when the compiled Fortran program is run and fails. On the other hand, perhaps the mmap call with its arguments is actually based on wrong assumptions and it's a real bug. Another thought: Even if the mmap call's length argument was just too big, would it be possible to access the memory in several chunks (mmap calls) to work around the argument issue and thus be able to use as much total memory as the operating system provides for the process?
Well you are allocating an 1.5gb bss segment. There is no room for this amount of contiguous memory on i?86. You might want to use allocatable arrays instead. Anyway, this is not a gcc bug.
> > ! call random_seed() ! doesn't seem to change anything It changes the seeds to the default settings. Please see the manual that came with gfortran. As to the other problem, follow Richard's advice and use a dynamic array.