Re: malloc() exceeds RLIMIT_DATA

[Thor Lancelot Simon <tls%panix.com@localhost>]

On Tue, Jul 09, 2019 at 10:24:53AM -0700, Graham Percival wrote:
> On Tue, Jul 09, 2019 at 07:17:39AM +0200, Martin Husemann wrote:
> > The classical "data segment" (limited by RLIMIT_DATA) is not used much
> > nowadays in NetBSD. Especially malloc() does not use it.
> > 
> >      RLIMIT_DATA     The maximum size (in bytes) of the data segment for a
> >                      process; this defines how far a program may extend its
> >                      break with the sbrk(2) system call.
> > 
> > 
> > In ancient times malloc allocated memory via sbrk(2), but nowadays it uses
> > mmap(2) with anonymous memory.
> 
> I have no complaint about the internal implementation of malloc().  But POSIX
> says that:
> 
>     RLIMIT_DATA
>     This is the maximum size of a data segment of the process, in bytes. If

I think you don't grasp what Martin's telling you.

POSIX does not precisely define "data segment of the process"; nor does it
state that there cannot be more than one.

Our implementation doesn't really have such; so, though it might be desirable
to ensure a process cannot allocate more than RLIMIT_DATA bytes, it is not
a violation that it cannot, so long as said allocations don't come from a
single "data segment of the process" (which in our implementation they do
not).

The concept of a process having a single "data segment" managed with sbrk()
is very old and is not really relevant to modern Unix implementations.  If
POSIX wants to redefine RLIMIT_DATA in some way more useful in the modern
era, this might be good; but as it stands, the problem is that the limit
is enforced, but it does not, perhaps, limit what many users initially
think it ought to.

Thor