What is the policy on out-of-memory?

[Ryan Saunders]

Howdy!

While hacking inside of DBus, I've repeatedly encountered places in the code where it attempts to handle out-of-memory conditions, returning FALSE to indicate OOM. I understand propagating this out of low level functions, but how & when does/should DBus decide to re-attempt an operation that failed due to OOM? Should the top-level auth code repeatedly (endlessly?) retry in the face of an OOM condition? Should it propagate back out to the transport layer? To the connection layer? All the way back to the client or server app?

And how is this being tested? Are we just hoping that it works, or do we have unit tests somewhere that simulate OOM and somehow verify the state of the connection? I kinda suspect that this isn't really being tested, as I think incorrect error handling is responsible for the @todo in dbus-auth.c that says "both sides may hang waiting for input from the other".

If we're not testing this, I question the value and safety of such a mechanism. Why not just exit(1) on OOM instead of pretending to handle it?

On a related note, supposing that we really do want/need to handle this, I noticed several places in the auth code where we're unable to distinguish OOM from a hard failure. I've begun to replace these functions returning dbus_bool_t with ones returning a dbus_result_t, a new enumerated type having values "success", "failure", and "need memory". As much as I detest COM, lacking try/catch semantics (ah, C++ how I miss you!), I suppose this sort of "HRESULT" style error propagation is all we've got. :-(

R