On Wed, 14 Apr 1999, Mikhail Teterin wrote:

> Steve Kargl once wrote:
> > /usr/ports/devel/libxalloc
> > /usr/ports/devel/libmalloc
> > /usr/ports/devel/libdlmalloc
> I do not see how they can guarantee the usability of the returned
> memory with the current kernel. There apparently is no way of
> knowing at malloc time if the memory can be used. Worse then that,
> it may be possible to use it at malloc time, but unless your program
> runs and touches every page, the memory may not be available later.
> If we are up to discussing the possible implementations, I'd suggest
> that the system uses something other then SIGKILL to notify the
> program it's time to pay for the over-commit speed and convenience.
> I think, SIGBUS is appropriate, but I'm not sure.
> Anything a program can _catch_ and react upon, if its author chooses
> to.

Design an impelementation says a SIGSEGV should be delivered afaik,
but that's only for anon mmap.  the problem with that is that you then
can tell if your allocator is buggy, or you have a memory problem...

> Then, one can write a safe malloc, which will install the signal
> handler, and touch every page in the the memory referenced by the
> to-be-returned pointer. If the signal handler is invoked in the
> progress, the to-be-returned memory must be returned back to the
> system and NULL should be returned to the caller.
> Whether or not to use this "safe" malloc can be determined by malloc
> options and/or the size of the request.
> However, my (in)ability to propose anything remotely sensible does
> not change the facts established in this painful thread. That our
> malloc does not conform to standards (for whatever reasons), and
> that something should be done about it. That "something" must start
> with documenting the flaw...

It's an impelementation, NOT a flaw.  there should be a sysctl
to force your "standard" impelementation, this current one is
great for servers, desktop boxes and shell boxes, however for
embedded systems where compenents shouldn't fail being killed
for using memory you "rightously allocated" or potentially causing
the death of an entirly different programming running is unnaceptable.

it also makes for a really big PITA to debug the reason why a totally 
unrelated process was killed.


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message

Reply via email to