OOM safety
Robert O'Callahan
Turns out that GTK, by design, exits in out-of-memory situations. That
makes our efforts to detect OOM and recover somewhat moot, on that
platform anyway.
But Nokia's Maemo platform uses GTK on embedded devices. Does anyone
know how they deal with OOM?
Rob
Dan Mosedale
> Context: https://bugzilla.mozilla.org/show_bug.cgi?id=335951
>
> Turns out that GTK, by design, exits in out-of-memory situations. That
> makes our efforts to detect OOM and recover somewhat moot, on that
> platform anyway.
Got a link to any sort of documentation about the motivation behind this
design? A quick Google search didn't turn up anything obvious...
Dan
Boris Zbarsky
> Turns out that GTK, by design, exits in out-of-memory situations.
It actually exits in situations where it just thinks it's out of memory, sadly.
We've had bugs on this before.
> That makes our efforts to detect OOM and recover somewhat moot, on that
> platform anyway.
Only OOM in calls to GTK. We can still usefully detect and recover from OOM for
other (esp. large) allocations.
-Boris
Chris Hofmann
> dev-platform mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
Antonio might know or be able to find someone who can answer...
chris h.
Robert O'Callahan
> Robert O'Callahan wrote:
>> That makes our efforts to detect OOM and recover somewhat moot, on that
>> platform anyway.
>
> Only OOM in calls to GTK. We can still usefully detect and recover from
> OOM for other (esp. large) allocations.
Yes, but we will never be able to reliably survive a persistent OOM
condition ... eventually we'll call into GTK and die.
Rob
Boris Zbarsky
> Yes, but we will never be able to reliably survive a persistent OOM
> condition ... eventually we'll call into GTK and die.
Yeah, indeed.
Could we push on the GTK folks to fix this? Say give the app control over the
OOM behavior?
-Boris
Robert O'Callahan
They would need to change a ton of code. I'd like to find out what the
folks who are embedding GTK think first ... they're the ones who would
really be suffering, you'd think.
Rob
Dan Mosedale
Well, at the very least, it gives us the opportunity to try and free up
a bunch of memory and/or gracefully shut down to avoid data corruption.
Dan
Darin Fisher
Maybe search and replace for exit? Replace it with g_maybe_exit that
invokes a user defined callback function or else invokes exit.
-Darin
Mike Shaver
> Maybe search and replace for exit? Replace it with g_maybe_exit that
> invokes a user defined callback function or else invokes exit.
That would avoid the immediate exit, but unless the allocation can be
retried and succeed, the callers must all be able to gracefully handle
NULL working its way back up the stack. I suspect that very few
callers will do so, since GTK style is very much not to check
allocation success (since, after all, it will exit rather than fail).
Mike
Andrew Schultz
> That would avoid the immediate exit, but unless the allocation can be
> retried and succeed, the callers must all be able to gracefully handle
> NULL working its way back up the stack. I suspect that very few
Beyond that, NULL wouldn't work its way back up the stack due to work
being done asynchronously. See
https://bugzilla.mozilla.org/show_bug.cgi?id=210931
--
Andrew Schultz
ajsc...@verizon.net
http://www.sens.buffalo.edu/~ajs42/
Doug Turner
Edjard Mota (of INDT) was working on a kernel patch which allowed you to
set an low and high water mark on memory usages -- so, before you even
had a OOM problem, your app would get signaled.
See for some details: http://www.linuxjournal.com/article/8502
However this doesn't buy us much on most platforms.
Doug
Doug Turner
Darin Fisher
> On 5/5/06, Darin Fisher <dar...@gmail.com> wrote:
> > Maybe search and replace for exit? Replace it with g_maybe_exit that
> > invokes a user defined callback function or else invokes exit.
>
> retried and succeed, the callers must all be able to gracefully handle
> NULL working its way back up the stack. I suspect that very few
> allocation success (since, after all, it will exit rather than fail).
longjmp! j/k... you're right... we'd need gtk to unwind cleanly and
leave itself in a consistent state.
-darin