Mac Intel

Bob Ippolito bob@REDACTED
Sun Aug 13 00:51:33 CEST 2006

On 8/12/06, Joel Reymont <joelr1@REDACTED> wrote:
> On Aug 12, 2006, at 10:24 PM, Mikael Pettersson wrote:
> > "region"? Assuming it's Erlang being unable to allocate more
> > memory, you should run the same test case (big_binary) in BEAM
> > to determine if the problem is HiPE-related or not.
> >
> > (Just c(big_binary) followed by big_binary:test() in the Erlang
> > shell.)
> Same result as with HiPE. Trace below. I have 2Gb of physical memory.
> Any tips?
> ---
> Erlang (BEAM) emulator version 5.5 [source] [async-threads:0] [hipe]
> Eshell V5.5  (abort with ^G)
> 1> c(big_binary).
> {ok,big_binary}
> 2> big_binary:test().
> beam(28985,0xa000cf60) malloc: *** vm_allocate(size=1074790400)
> failed (error code=3)
>       beam(28985,0xa000cf60) malloc: *** error: can't allocate region

This error means that there's not enough space left in the VM to
acquire that much RAM. You should get the same error on PPC unless
they've done something to work around it.

One common cause of this is attempting to use the realloc() call in
hopes of shrinking a large allocation. That does not ever happen on
Mac OS X. realloc(ptr, N) where N is <= size currently allocated is
always a no-op (no other VM does this "optimization" to my knowledge).
If you download the libc source from Apple and look at the
implementation it's pretty clear that this is the case.

I'm not familiar with the Erlang internals, but I've seen this problem
occur in Python in extension code that allocates a large buffer (e.g.
for non-blocking IO), reads into it, and then realloc's it to a
smaller size expecting the unused part to be reclaimed. The socket
extension can cause this if used in certain patterns:


More information about the erlang-questions mailing list