[olpc-software] graceful handling of out-of-memory conditions
Daniel P. Berrange
berrange at redhat.com
Tue Mar 28 12:22:43 UTC 2006
On Tue, Mar 28, 2006 at 01:11:09PM +1000, Martin Sevior wrote:
> On Tue, 2006-03-28 at 02:56 +0100, Daniel P. Berrange wrote:
>
> > So while we could put lots of research into figuring out an optimal OOM handling
> > solution, I think we'd be better off picking a simple algorithm, and then focusing
> > effort on modifying applications such that in the event they are killed off, no
> > user data is lost. Such modifications would be useful beyond post OOM handling, eg
> > post a SEGV crash a user wouldn't loose data. Or it would enable a window manager
> > to proactively shutdown apps before an OOM situation is even encountered.
>
> As a data point in this discussion, AbiWord has a segfault handler that
> saves the current document to disk upon receiving a variety of signals
> including 11 of course.
>
> I'll have to look at the code to see if we require memory allocation to
> write the data to disk. We probably do. We might be able to save the
> situation by releasing memory before writing to disk.
I rather hope AbiWord doesn't need memory allocation if its running an
autosave in a SEGV handler - all bets are off when a process receives,
a SEGV - the chances of malloc() continuing to work are slim. I've lost
count of the number of crash debugging exercises where I needed a LD_PRELOAD
library to override a SEGV handler which was doing something which just
caused further corruption / SEGVs!
If it really is neccessary to do work in a SEGV handler, one must at least
pre-allocate any memory one expects to need, and also preferrably allocate
an altsigstack. Even then expect it fail a percentage of the time.
If the overhead of performing the auto-save can be reduced to a level
where the user won't notice any delay, then it'd be preferrable to autosave
continuously throughout use - say after 'x' kb more text have been entered
in a document, or when an non-trivial operation of is performed on a doc,
or say when the window manager minimizes the document window.
> Is it possible to provide a signal to a process upon receiving a an Out
> Of Memory rather than just returning a NULL pointer? While returning
> NULL pointers will almost certainly cause AbiWord to segfault it would
> nicer to know that the segfault was actually an OOM event rather than a
> bug in the code. If the former we would know it was appropriate to
> delete classes (to release memory) and to give an appropriate document
> name, if the latter it make more sense to dump the document as quickly
> as possible.
Dan
--
|=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=|
|=- Perl modules: http://search.cpan.org/~danberr/ -=|
|=- Projects: http://freshmeat.net/~danielpb/ -=|
|=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|
More information about the olpc-software
mailing list