diff options
author | Mikael Pettersson <[email protected]> | 2010-08-11 19:31:43 +0200 |
---|---|---|
committer | Björn Gustavsson <[email protected]> | 2010-08-13 11:03:44 +0200 |
commit | 6b8733b2b7e240bbda505b10e6e443f9278451b8 (patch) | |
tree | aac9d8a2daa0e74751a416f5cfe13110a8f45c6e /Makefile.in | |
parent | 871fdb232d7facc58c202ef81634a12fbdcfefb4 (diff) | |
download | otp-6b8733b2b7e240bbda505b10e6e443f9278451b8.tar.gz otp-6b8733b2b7e240bbda505b10e6e443f9278451b8.tar.bz2 otp-6b8733b2b7e240bbda505b10e6e443f9278451b8.zip |
fix hipe_bifs_alloc_data_2 to avoid "Yikes!" warning
It's been reported that HiPE-enabled Erlang VMs running on BSD
systems sometimes generate messages like
Yikes! erts_alloc() returned misaligned address 0x8016a512c
These originate from hipe_bif0.c:hipe_bifs_alloc_data_2().
A native code module has an associated data area of some
size and alignment. In the case where the size is zero,
the alignment is irrelevant, but the allocation BIF checks
it anyway. The warning then triggers on systems where
malloc(0) returns blocks with less alignment than we
(erroneously) expected.
The fix is to simply skip the allocation in this case and
return NULL. The loader won't actually use the address in
this case so that's safe. This is also an optimization since
it avoids allocating memory that cannot be used, and it avoids
fragmenting the system heap with useless tiny blocks.
A second problem is that the warning message failed to
identify its origin. Fixed by prefixing the message by
the BIF's name rather than the silly Yikes! string.
Tested and confirmed to solve the original reporter's problem.
Diffstat (limited to 'Makefile.in')
0 files changed, 0 insertions, 0 deletions