Ethereal-dev: Re: [Ethereal-dev] What to do, if Ethereal is running out of memory?
Guy Harris wrote:
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()".
Yes, that's exactly what I meant with "or functions which uses them".
(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()".
I would think, that there are a lot of other functions using g_alloc,
like GTK functions creating Widgets and such.
So it will be impossible to prevent using any of these g_alloc calls
without preventing any GTK/Glib functions at all :-(
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.
As the roots of the GTK libs are the Gimp, I wonder how they handle that
problem. The Gimp can load very large pictures (a few hundred MB's),
which could lead to the same problem.
One solution to this problem might be to have a trigger for something
like a memory low water mark (how to create that event?). So if there
are less than let's say 10MB free RAM (user preference), this could
create an event to stop capturing or loading data. I know that this
isn't a 100% solution, but a lot better than today IMHO.
Regards, ULFL
