["Guy Harris" <gharris@xxxxxxxxx>]

Ulf Lamping said:
> Having a look at the memory allocation documentation of glib (as we
> typically use g_alloc/g_free, or functions which uses them), I found:

Yes, we know.

One problem, though, is that a number of GLib routines themselves use
"g_malloc()", so even if Ethereal were to stop using "g_malloc()" (and,
instead, to check call "malloc()", check for a null return value, and
terminate whatever it's doing and clean up if it returns null), we'd
*still* run the risk of aborting - so we'd have to stop using any GLib
routines that call "g_malloc()".

> (http://developer.gnome.org/doc/API/2.0/glib/glib-Memory-Allocation.html)
>
> Hmm, and I don't see a way how we can circumvent that.

At least in GLib 2.2.3 (and presumably later), there's "g_try_malloc()".

Unfortunately, that's *not* what, for example, is used by GHashTable - it
uses "g_new()" and "g_new0()", which are wrappers around "g_malloc()".

You could also, in theory, use (at least in those versions of GLib that
support it, which might mean 2.0 only) use "g_mem_set_vtable()" to supply
our own allocation routines - but the problem is that GLib and probably
GTK+ as well assume "g_malloc()" never returns a null pointer.

> Or maybe a good suggestion for the GTK/GLib people to find a long term
> solution for this?

I seem to remember that, a few years ago, the idea of having some sort of
hook to catch allocation failures was discussed on the GTK+ development
mailing list; I think I remember at least some GTK+/GLib core developers
being opposed to the idea, although I don't remember the details.