------- Comment #2 from sschwarzer at sschwarzer dot net 2009-09-06 13:22
-------
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?
--
sschwarzer at sschwarzer dot net changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |UNCONFIRMED
Resolution|INVALID |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41283
