malloc(3)/realloc(3) on MacOSX doesn't always take rlimit into account.
Imported from http://bugzilla.roxen.com/bugzilla/show_bug.cgi?id=1464
Reported by @grubba
This has the effect that the binary will instead fail when the memory is used. The program will print the message: "*** malloc[29683]: error for object 0xf42000: Can't vm_copy region". and then die of signal EXC_BAD_ACCESS.
Example:
Doing test 6412 (6412 total) 1: mixed a() { return search(sprintf("%'"+"+-*"+"'*n"+"SUNE",100000+1),"SUNE"); } 2: mixed b() { return 100000+1; } *** malloc[29683]: error for object 0xf42000: Can't vm_copy region
Program received signal EXC_BAD_ACCESS, Could not access memory.
realloc_unlinked_string (a=0xf42000, size=200002) at
/home/grubba/src/Pike/7.3/src/stralloc.c:1376
1376 r->len=size;
(gdb) p r
$1 = (struct pike_string *) 0xf5b000
(gdb) p *r
Cannot access memory at address 0xf5b000
(gdb) p a
$2 = (struct pike_string *) 0xf42000
(gdb) p *a
$3 = {
refs = 0,
size_shift = 0,
len = 100001,
hval = 160790766,
next = 0xffffffff,
str = "+"
}
r is the return value from realloc(3), or from begin_wide_shared_string() (which translates to malloc(3)), and should be NULL if the memory couldn't be allocated.
The MacOSX manualpage for malloc(3) does not mention this behaviour, so it's most likely a bug in libc.