What is the policy on out-of-memory?

[Scott James Remnant]

On Mon, 2009-01-12 at 18:31 -0800, Ryan Saunders wrote:

> > Exactly, the out-of-memory should be propagated to the app. Most apps
> > just ignore it, of course. But if there's a retry it happens at the
> > app level.
> 
> Interesting. Not exactly straightforward, though, since developers
> often fail to think thru all the possible ways a thing could fail. 
> 
While true, there are applications using D-Bus for which it is
unacceptable that the library spin in out of memory situations.

The most obvious example is init - if the D-Bus library is spinning,
then init will not be reaping zombie children, so free memory may not be
being returned to the system.

> The auth hang, for example happens because the function
> _dbus_transport_get_is_authenticated calls a whole bunch of auth code,
> which may fail, but does not propagate OOM. Thus, the caller
> (do_authentication) interprets the result FALSE as "not
> authenticated", and then proceeds to call "exchange_credentials". But
> in an OOM situation, it's really easy for the auth stuff to internally
> be in the wrong state at that point, because it's difficult to ensure
> (and validate!) that the auth is actually rolled back to a consistent
> state when OOM happens. I suspect that the transport layer code may
> have similar issues lurking (e.g., socket opened successfully, some
> data is read from it and processed, then OOM...how do we guarantee
> that the transport code is in a consistent state? Do we "un-read" the
> data back into the buffer? Do we
>  shut down the transport entirely?).
> 
This sounds wrong - if authentication fails, the connection should be
dropped.

Scott
-- 
Scott James Remnant
scott at canonical.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
Url : http://lists.freedesktop.org/archives/dbus/attachments/20090113/77ef66c0/attachment.pgp