public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug fortran/50924] New: Attempt to allocate negative amount of memory. Possible integer overflow
@ 2011-10-30 17:57 fwi at inducks dot org
2011-10-30 18:52 ` [Bug fortran/50924] " fwi at inducks dot org
` (3 more replies)
0 siblings, 4 replies; 5+ messages in thread
From: fwi at inducks dot org @ 2011-10-30 17:57 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50924
Bug #: 50924
Summary: Attempt to allocate negative amount of memory.
Possible integer overflow
Classification: Unclassified
Product: gcc
Version: 4.4.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned@gcc.gnu.org
ReportedBy: fwi@inducks.org
When allocating a large array the progrem stops with:
Fortran runtime error: Attempt to allocate negative amount of memory. Possible
integer overflow
Test program:
PROGRAM MAIN
DOUBLE PRECISION, ALLOCATABLE :: E(:,:,:)
INTEGER :: N
N=645
ALLOCATE(E(N,N,N))
DEALLOCATE(E)
END PROGRAM MAIN
With N=646:
$ gfortran -fbacktrace -g test.f90 && ./a.out
Fortran runtime error: Attempt to allocate negative amount of memory. Possible
integer overflow
Backtrace for this error:
+ /lib/tls/i686/cmov/libc.so.6(__libc_start_main+0xe6) [0xe2dbd6]
With N=645, the program works fine and takes 68.5% of the memory, so there
should be enough room for a 646^3 array (no other program is using a
significant amount of memory).
I believe the problem is that sizeof(double)=8 so the array size is:
8*(645^3) = 2 146 689 000
8*(646^3) = 2 156 689 088
and: 2^31 = 2 147 483 648
So my guess is that the total amount of memory needed for the array is saved in
some integer, which overflows and become negative.
If that's of any use:
$ cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 23
model name : Intel(R) Celeron(R) CPU E3300 @ 2.50GHz
stepping : 10
cpu MHz : 2493.807
cache size : 1024 KB
physical id : 0
siblings : 2
core id : 0
cpu cores : 2
apicid : 0
initial apicid : 0
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat
pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm constant_tsc
arch_perfmon pebs bts aperfmperf pni dtes64 monitor ds_cpl vmx est tm2 ssse3
cx16 xtpr pdcm xsave lahf_lm tpr_shadow vnmi flexpriority
bogomips : 4987.61
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:
processor : 1
vendor_id : GenuineIntel
cpu family : 6
model : 23
model name : Intel(R) Celeron(R) CPU E3300 @ 2.50GHz
stepping : 10
cpu MHz : 2493.807
cache size : 1024 KB
physical id : 0
siblings : 2
core id : 1
cpu cores : 2
apicid : 1
initial apicid : 1
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat
pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm constant_tsc
arch_perfmon pebs bts aperfmperf pni dtes64 monitor ds_cpl vmx est tm2 ssse3
cx16 xtpr pdcm xsave lahf_lm tpr_shadow vnmi flexpriority
bogomips : 4987.44
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:
$ cat /etc/lsb-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=10.04
DISTRIB_CODENAME=lucid
DISTRIB_DESCRIPTION="Ubuntu 10.04.3 LTS"
Thanks.
^ permalink raw reply [flat|nested] 5+ messages in thread
* [Bug fortran/50924] Attempt to allocate negative amount of memory. Possible integer overflow
2011-10-30 17:57 [Bug fortran/50924] New: Attempt to allocate negative amount of memory. Possible integer overflow fwi at inducks dot org
@ 2011-10-30 18:52 ` fwi at inducks dot org
2011-10-30 18:55 ` kargl at gcc dot gnu.org
` (2 subsequent siblings)
3 siblings, 0 replies; 5+ messages in thread
From: fwi at inducks dot org @ 2011-10-30 18:52 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50924
fwi at inducks dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |fwi at inducks dot org
--- Comment #1 from fwi at inducks dot org 2011-10-30 18:52:10 UTC ---
NB: my system is 32-bit
^ permalink raw reply [flat|nested] 5+ messages in thread
* [Bug fortran/50924] Attempt to allocate negative amount of memory. Possible integer overflow
2011-10-30 17:57 [Bug fortran/50924] New: Attempt to allocate negative amount of memory. Possible integer overflow fwi at inducks dot org
2011-10-30 18:52 ` [Bug fortran/50924] " fwi at inducks dot org
@ 2011-10-30 18:55 ` kargl at gcc dot gnu.org
2011-10-30 21:55 ` rguenth at gcc dot gnu.org
2011-10-31 8:43 ` fwi at inducks dot org
3 siblings, 0 replies; 5+ messages in thread
From: kargl at gcc dot gnu.org @ 2011-10-30 18:55 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50924
kargl at gcc dot gnu.org changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |kargl at gcc dot gnu.org
--- Comment #2 from kargl at gcc dot gnu.org 2011-10-30 18:55:09 UTC ---
(In reply to comment #1)
> NB: my system is 32-bit
What happens if you use 'INTEGER(8) N'?
You may simply be hitting an OS problem. Your code
fails on i686-*-freebsd and runs fine on x86_64-*-freebsd.
The moral seems to be if you want to grab large chunks
of memory, get hardware that will it.
^ permalink raw reply [flat|nested] 5+ messages in thread
* [Bug fortran/50924] Attempt to allocate negative amount of memory. Possible integer overflow
2011-10-30 17:57 [Bug fortran/50924] New: Attempt to allocate negative amount of memory. Possible integer overflow fwi at inducks dot org
2011-10-30 18:52 ` [Bug fortran/50924] " fwi at inducks dot org
2011-10-30 18:55 ` kargl at gcc dot gnu.org
@ 2011-10-30 21:55 ` rguenth at gcc dot gnu.org
2011-10-31 8:43 ` fwi at inducks dot org
3 siblings, 0 replies; 5+ messages in thread
From: rguenth at gcc dot gnu.org @ 2011-10-30 21:55 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50924
Richard Guenther <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |RESOLVED
Resolution| |INVALID
--- Comment #3 from Richard Guenther <rguenth at gcc dot gnu.org> 2011-10-30 21:55:06 UTC ---
The maximum object size that can be allocated is half of the virtual
address-space. Your object is too large (this is a middle-end restriction,
documented
in the C implementation defined section of the manual - the same restriction
applies to fortran).
^ permalink raw reply [flat|nested] 5+ messages in thread
* [Bug fortran/50924] Attempt to allocate negative amount of memory. Possible integer overflow
2011-10-30 17:57 [Bug fortran/50924] New: Attempt to allocate negative amount of memory. Possible integer overflow fwi at inducks dot org
` (2 preceding siblings ...)
2011-10-30 21:55 ` rguenth at gcc dot gnu.org
@ 2011-10-31 8:43 ` fwi at inducks dot org
3 siblings, 0 replies; 5+ messages in thread
From: fwi at inducks dot org @ 2011-10-31 8:43 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50924
--- Comment #4 from fwi at inducks dot org 2011-10-31 08:43:23 UTC ---
Actually contrary to what I wrote my system is 64 bit (I clicked on "edit" on
the top right and somehow the system sent a message that I was starting to
write).
Still when I run my program on a 64-bit machine with 16 Gb of RAM (under
CentOS), I could fill up 96% of the RAM with just one big array. I don't really
understand why such restriction is enforced.
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2011-10-31 8:43 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-10-30 17:57 [Bug fortran/50924] New: Attempt to allocate negative amount of memory. Possible integer overflow fwi at inducks dot org
2011-10-30 18:52 ` [Bug fortran/50924] " fwi at inducks dot org
2011-10-30 18:55 ` kargl at gcc dot gnu.org
2011-10-30 21:55 ` rguenth at gcc dot gnu.org
2011-10-31 8:43 ` fwi at inducks 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).