What is the policy on out-of-memory?

[Ryan Saunders]

> The OOM is propagated through _dbus_auth_do_work which can return an

> OOM state. exchange_credentials() can also return FALSE on OOM. So it
> may just be a matter of bumping the OOM through get_is_authenticated
> and up to avoid the exchange_credentials(). (Run the "exchange
> credentials returned FALSE" codepath if get_is_authenticated gets OOM,
> in essence.) Something along those lines. Maybe just add a
> get_is_authenticated variant and keep using the current one elsewhere,
> if that works.

OK, I'll look into that. Seems like it should be workable.


> > 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?).
>
> The approach in the bus daemon for oom in most cases is to report an
> error for the current message and roll back all handling of that
> message. There are few allocations that aren't in the context of
> processing a particular message.
> 
> For auth failure, I think it's a fine OOM response to simply fail to
> complete the connection and drop the connection.

Alright. I'll try to ensure that this is what happens. The problem right now is that (a) the OOM doesn't propagate all the way out, and (b) memory allocations aren't the only state changes that happen, and changes to auth state aren't transacted. If we just blow away the auth structures on OOM, that should sidestep the issue.


> > If DBus really must be C only, then it really needs some sort of brute-force OOM simulator unit test.
> >... I'll bet you'll find a lot of issues that way.
>
> In fact the dbus "make check" does exactly as you describe - great
> minds? It did find a lot of issues, but also gives some confidence
> that things mostly work as they are now.
> http://log.ometer.com/2008-02.html#4.2

Hmmm...ok. I had taken a quick peek at the unit test code before, but I didn't notice the memory torture test at the time. That makes me feel a lot better...

R