- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
$ uname -a
Darwin lion.nag.co.uk 11.2.0 Darwin Kernel Version 11.2.0: Tue Aug 9 20:54:00 PDT 2011; root:xnu-1699.24.8~1/RELEASE_X86_64 x86_64
$ ifort -V
Intel Fortran Intel 64 Compiler XE for applications running on Intel 64, Version 12.1.1.246 Build 20111011
$ cat big_alloc.f90
real, Allocatable :: x(:,:)
integer d, m, alloc_stat
d = int(1.6*huge(1)**0.25)
m = (d+1)*(d+2)/2 + 2
Allocate (x(d,m),Stat=alloc_stat)
end
$ ifort -i8 big_alloc.f90 ; ./a.out
a.out(81731) malloc: *** mmap(size=1371091381248000) failed (error code=12)
*** error: can't allocate region
*** set a breakpoint in malloc_error_break to debug
alloc_stat is correctly set as /= 0, so this is just a bit unsightly really.
It doesn't seem to happen on Linux.
I'm not really a Mac user, so I'm not sure what other info to send that would be helpful!
Darwin lion.nag.co.uk 11.2.0 Darwin Kernel Version 11.2.0: Tue Aug 9 20:54:00 PDT 2011; root:xnu-1699.24.8~1/RELEASE_X86_64 x86_64
$ ifort -V
Intel Fortran Intel 64 Compiler XE for applications running on Intel 64, Version 12.1.1.246 Build 20111011
$ cat big_alloc.f90
real, Allocatable :: x(:,:)
integer d, m, alloc_stat
d = int(1.6*huge(1)**0.25)
m = (d+1)*(d+2)/2 + 2
Allocate (x(d,m),Stat=alloc_stat)
end
$ ifort -i8 big_alloc.f90 ; ./a.out
a.out(81731) malloc: *** mmap(size=1371091381248000) failed (error code=12)
*** error: can't allocate region
*** set a breakpoint in malloc_error_break to debug
alloc_stat is correctly set as /= 0, so this is just a bit unsightly really.
It doesn't seem to happen on Linux.
I'm not really a Mac user, so I'm not sure what other info to send that would be helpful!
Link Copied
6 Replies
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I am not a Mac user, either, so this is just a guess: the message is probably from the underlying C library rather than from the Intel Fortran runtime. Sometimes there is an environmental variable that can be set to control messages from MALLOC and even to control subsequent action.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Mat,
The problem is:
with default integer(4) huge(1) == 2147483647
d becomes 344, n becomes 59687
x(344,59687) * 4 = 82,129,312 bytes
with default integer(8) huge(1) ==9223372036854775807
d becomes 88174, n becomes 3887459402
x(88174,3887459402) * 4 =1,371,091,381,247,792 bytes
Jim Dempsey
The problem is:
with default integer(4) huge(1) == 2147483647
d becomes 344, n becomes 59687
x(344,59687) * 4 = 82,129,312 bytes
with default integer(8) huge(1) ==9223372036854775807
d becomes 88174, n becomes 3887459402
x(88174,3887459402) * 4 =1,371,091,381,247,792 bytes
Jim Dempsey
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Jim, your estimate is
x(88174,3887459402) * 4 =1,371,091,381,247,792 bytes
which, when rounded up, matches the value in the MALLOC error message,
mmap(size=1371091381248000) failed (error code=12)
This is about 1.4 petabytes.
x(88174,3887459402) * 4 =1,371,091,381,247,792 bytes
which, when rounded up, matches the value in the MALLOC error message,
mmap(size=1371091381248000) failed (error code=12)
This is about 1.4 petabytes.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
It's unfortunate though that it gets exposed like this. Wouldn't you expect the compiler to trap and control the subsequent action itself?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks. I'm expecting the allocation to fail. The problem is that there's a nasty error message bubbling up from the guts of _somewhere_.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
>>The problem is that there's a nasty error message bubbling up from the guts of _somewhere_.
It is bubling up from the C Runtime Library in the malloc function.
This is not an Intel Visual Fortran issue. It is an issue with the C Runtime Library as it interfaces with the O/S. In your case this is the MAC O/S. Consult with/on the MAC forums relating to too large of allocations causing error trap as opposed to returning NULL.
Jim Dempsey
It is bubling up from the C Runtime Library in the malloc function.
This is not an Intel Visual Fortran issue. It is an issue with the C Runtime Library as it interfaces with the O/S. In your case this is the MAC O/S. Consult with/on the MAC forums relating to too large of allocations causing error trap as opposed to returning NULL.
Jim Dempsey

Reply
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page