Re: When should ralloc.c be used?

[jca@wxcvbn.org (Jérémie Courrèges-Anglas)]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> I wouldn't have thought that PROT_NONE vs PROT_READ|PROT_WRITE would
>> have changed anything here, but on *some* OSes it does, however it is
>> not portable.  At least OpenBSD doesn't behave like what you describe.
>
> Are you sure?  Can you point to concrete evidence?

Erm, I think there was a problem with my tests.

data:
- system has 8GB of ram
- no swap
- "data" rlimit set to 32GB, the per-process maximum supported on
  OpenBSD/amd64

with Daniel's test program asking for 20GB:
- mmap(PROT_NONE) _succeeds_
- mprotect(PROT_READ|PROT_WRITE) _succeeds_

An mmap call directly asking for 20GB with PROT_READ|PROT_WRITE also
succeeds.  The protection flags aren't checked to decide whether ENOMEM
should be returned, and the process has no easy way to tell whether the
requested amount of memory is actually usable (-> SIGBUS if the system
can't map enough pages).

The reason why my test initially failed is that I assumed that ulimit -d
was 4GB on this box, not 1.5GB (default for OpenBSD/amd64).  Not
double-checking this was sloppy, my sincere apologies to Daniel and the
other readers.

> Not that's it's important (using a hard-coded number like 2GB wouldn't
> work, so we'd more likely use something like w32heap.c's "pre-allocate
> double the size", which doesn't suffer from that problem anyway and
> still guarantees efficient behavior when growing a buffer progressively
> from 1B to 100GB).

Ack.  Note that the test above was using the maximum value for
ulimit -d; for the record, a single allocation of 2GB would be rejected
by default on all of our supported platforms.

-- 
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE