public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug fortran/41283] New: Generated program gets killed on subsequent calls to random_number on "double precision" arrays of size 100000000 (1e8)
@ 2009-09-06 9:02 sschwarzer at sschwarzer dot net
2009-09-06 9:40 ` [Bug fortran/41283] " rguenth at gcc dot gnu dot org
` (3 more replies)
0 siblings, 4 replies; 5+ messages in thread
From: sschwarzer at sschwarzer dot net @ 2009-09-06 9:02 UTC (permalink / raw)
To: gcc-bugs
$ 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.
--
Summary: Generated program gets killed on subsequent calls to
random_number on "double precision" arrays of size
100000000 (1e8)
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sschwarzer at sschwarzer dot net
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41283
^ permalink raw reply [flat|nested] 5+ messages in thread
* [Bug fortran/41283] Generated program gets killed on subsequent calls to random_number on "double precision" arrays of size 100000000 (1e8)
2009-09-06 9:02 [Bug fortran/41283] New: Generated program gets killed on subsequent calls to random_number on "double precision" arrays of size 100000000 (1e8) sschwarzer at sschwarzer dot net
@ 2009-09-06 9:40 ` rguenth at gcc dot gnu dot org
2009-09-06 13:22 ` sschwarzer at sschwarzer dot net
` (2 subsequent siblings)
3 siblings, 0 replies; 5+ messages in thread
From: rguenth at gcc dot gnu dot org @ 2009-09-06 9:40 UTC (permalink / raw)
To: gcc-bugs
------- Comment #1 from rguenth at gcc dot gnu dot org 2009-09-06 09:40 -------
You use too much memory and your operating system kills your program for that.
Read on ulimit(8).
--
rguenth at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |RESOLVED
Resolution| |INVALID
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41283
^ permalink raw reply [flat|nested] 5+ messages in thread
* [Bug fortran/41283] Generated program gets killed on subsequent calls to random_number on "double precision" arrays of size 100000000 (1e8)
2009-09-06 9:02 [Bug fortran/41283] New: Generated program gets killed on subsequent calls to random_number on "double precision" arrays of size 100000000 (1e8) sschwarzer at sschwarzer dot net
2009-09-06 9:40 ` [Bug fortran/41283] " rguenth at gcc dot gnu dot org
@ 2009-09-06 13:22 ` sschwarzer at sschwarzer dot net
2009-09-06 14:46 ` rguenth at gcc dot gnu dot org
2009-09-06 16:25 ` kargl at gcc dot gnu dot org
3 siblings, 0 replies; 5+ messages in thread
From: sschwarzer at sschwarzer dot net @ 2009-09-06 13:22 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 5+ messages in thread
* [Bug fortran/41283] Generated program gets killed on subsequent calls to random_number on "double precision" arrays of size 100000000 (1e8)
2009-09-06 9:02 [Bug fortran/41283] New: Generated program gets killed on subsequent calls to random_number on "double precision" arrays of size 100000000 (1e8) sschwarzer at sschwarzer dot net
2009-09-06 9:40 ` [Bug fortran/41283] " rguenth at gcc dot gnu dot org
2009-09-06 13:22 ` sschwarzer at sschwarzer dot net
@ 2009-09-06 14:46 ` rguenth at gcc dot gnu dot org
2009-09-06 16:25 ` kargl at gcc dot gnu dot org
3 siblings, 0 replies; 5+ messages in thread
From: rguenth at gcc dot gnu dot org @ 2009-09-06 14:46 UTC (permalink / raw)
To: gcc-bugs
------- Comment #3 from rguenth at gcc dot gnu dot org 2009-09-06 14:46 -------
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.
--
rguenth at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |RESOLVED
Resolution| |INVALID
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41283
^ permalink raw reply [flat|nested] 5+ messages in thread
* [Bug fortran/41283] Generated program gets killed on subsequent calls to random_number on "double precision" arrays of size 100000000 (1e8)
2009-09-06 9:02 [Bug fortran/41283] New: Generated program gets killed on subsequent calls to random_number on "double precision" arrays of size 100000000 (1e8) sschwarzer at sschwarzer dot net
` (2 preceding siblings ...)
2009-09-06 14:46 ` rguenth at gcc dot gnu dot org
@ 2009-09-06 16:25 ` kargl at gcc dot gnu dot org
3 siblings, 0 replies; 5+ messages in thread
From: kargl at gcc dot gnu dot org @ 2009-09-06 16:25 UTC (permalink / raw)
To: gcc-bugs
------- Comment #4 from kargl at gcc dot gnu dot org 2009-09-06 16:25 -------
>
> ! 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.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41283
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2009-09-06 16:25 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-09-06 9:02 [Bug fortran/41283] New: Generated program gets killed on subsequent calls to random_number on "double precision" arrays of size 100000000 (1e8) sschwarzer at sschwarzer dot net
2009-09-06 9:40 ` [Bug fortran/41283] " rguenth at gcc dot gnu dot org
2009-09-06 13:22 ` sschwarzer at sschwarzer dot net
2009-09-06 14:46 ` rguenth at gcc dot gnu dot org
2009-09-06 16:25 ` kargl at gcc dot gnu dot org
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).