[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: malloc() patches round 3

From: Thomas Bushnell, BSG
Subject: Re: malloc() patches round 3
Date: 22 Aug 2001 16:42:31 -0700
User-agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7

Igor Khavkine <i_khavki@alcor.concordia.ca> writes:

> There are still problems in libpager though.  In
> _pager_lock_object() and pager_change_attributes(), malloc() is used
> without its return value being checked. Both functions are void and
> the semantics of their use (as far as I can tell) do not allow to
> check for errors easily.

In _pager_lock_object, malloc is only used when SYNC is true.  This is
an internal route, and how errors might get sent up depends on the
caller.  The possibilities are:

  The kernel is asking for permission to write the page.  The
  synchronous call to lock_object occurs if the library user says the
  unlock cannot succeed and an error should be sent to the kernel.  We
  *must* synchronously flush the page before marking the error bit
  set (with _pager_mark_request_next_error).  The sequel is that the
  kernel requests the page back and gets an error.
  The only fix I can think of in the event of memory exhaustion is to
  delay and retry.

pager_flush, pager_flush_some, pager_return, pager_return_some,
pager_sync, pager_sync_some:
  These are library user functions; they could be changed to return
  errors.  Note however that most of their callers cannot tolerate

Similar comments apply to pager_change_attributes.

> Since this is a support library, I would prefer that it did not by itself
> terminate the running process under any circumstances and propagted
> all errors to the programs that use it, however there are always excetions.
> So should the fix be a simple assert() statement or shoul I look into
> libpager in more detail to be able to propagate these errors?

I would prefer assert().

I have no objection to being more diligent about checking malloc
returns, but I have *NEVER* seen a Unixoid system perform anything
like sensibly in the event of virtual memory exhaustion.  The Mach
kernel itself just crashes directly.  And that's *better* than
diligently returning errors and trying to poke along, because it
actually *fixes* the problem: the system comes up again, and works.
Every system I've seen, when memory exhaustion happens, simply never
functions right again until rebooted.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]