Re: out-of-mem handler

[Havoc Pennington <hp redhat com>]

Tim Janik <timj@gtk.org> writes: 
> you make it sound like not having this sleep-in-malloc hack would cause
> crashes in gnome-session, which is just not true. first, g_malloc() doesn't
> *crash* on out of mem conditions, but gives an error message and aborts the
> program, this is way different than random untracable and unproduceble
> crashes. 

It is not different. Users will not be able to tell the
difference. You still lose all your data. End users do not read
~/.xsession-errors.

The fact that it is a planned bug doesn't keep it from being a bug.

> second, as far as i know, gnome-session doesn't allocate huge
> amounts memory, so if it encounters out-of-mem conditions, all other apps
> will be out of mem as well, i.e. your window manager, the x server, etc...
> it's not like only gnome-session had this problem in such situations.
> 

The idea is that generally running out of virtual memory is due to one
application with a memory leak, or starting up a single app like
StarOffice that uses ungodly amounts of RAM. However, whichever
application happens to try to alloc memory next is the one that
crashes. Typically, applications keep crashing randomly until the
memleaking or bloated app finally happens to fall over.

However, as long as gnome-session isn't the one that crashes, you can
recover; gnome-session can restart the window manager, etc. once the
memleaking app is dead and the problem is past. If gnome-session just
sleeps for a few seconds then the broken app will almost certainly be
gone after that time. The X server you're right is a real problem, and
should likely also be fixed somehow if possible. If not then fixing
gnome-session at least improves our chances of surviving the memory
crisis.

The fact that _all_ apps can't recover is not relevant, we don't want
them to in fact because if they all tried to recover you'd never get
out of the memory crisis. We just want gnome-session to be able to
avoid the total desktop meltdown by restoring the panel, etc. (it
already does restore the panel if it crashes). i.e. this behavior
makes sense for gnome-session only.

> at the bottom line, you are trying to partly-patch a fairly rare error
> condition in one program with doubtfull benefit, by sugesting to add an
> unreliable hack to glib.
> 

The hack is _not_ unreliable and it isn't really even a hack. The
particular actions someone chooses to take in their error handler may
be unreliable, but that is not in glib. glib reliably calls the error
handler (assuming there's stack space to even call g_error).

The change adds 5 or 6 lines of code and causes zero decrease in
efficiency, with zero maintenance requirements and zero impact on
behavior seen by existing or future apps that don't use the feature.
It is totally invisible to apps that don't use it.

The error handler is also generally useful because people may have
their own ideas about what to do on out-of-memory errors. I know you
can override g_error() but you can't override memory errors
specifically right now using glib. Certainly there have been a number
of posts to gtk-list where people were unhappy with this situation.

> (note that i'm not telling you that you should keep your hands off of
> gnome-session, just that glib is very probably the wrong place to
> hack up. rather, go for direct malloc/realloc/free interventions on
> platforms that support it, if you are really convinced of the benefits
> of your approach)
> 

That's an elaborate and hard-to-implement nonportable hack that may or
may not even be possible and almost certainly no one will get around
to. The glib change is portable, simple, and trivial.

In addition as I said, the gnome-session hack isn't the only use for
an error handler, you can also use it if you just want to die in a
different way than g_error().

Regardless of conclusions on this, we still should probably add the
g_malloc_try() etc. functions.

Havoc