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

Re: [olpc-software] graceful handling of out-of-memory conditions

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.

|=- 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  -=| 

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