Re: Proposal: g_set_out_of_mem_handler

[Owen Taylor <otaylor redhat com>]

First, as neat as Sebastian's proposal is, I have to say that
I like Havoc's ideas a lot more. They are much (much) simpler
which is important, and are less likely to conflict with other
systems that overload malloc(), or to run into portability
problems. (After all GLib now works on Win32, BeOS, OpenVMS,
and other such systems that I suspect don't even have brk().)

In general, I think trying too hard on this issue is not a good idea;
we are never going to get that absolute "robustness" that seem to
drive the demand for this without completely rewriting GLib and GTK+
to propagate errors everywhere. Which, along with being totally
impractical at this point , I suspect would actually decrease the
effective robustness of GTK+ by hiding many of the warnings you get
now if you don't check errors.

(And no, longjump() exceptions are not an answer ... without language
support for stack frame cleanup, they are just a bad idea... not to
mention what happens if you throw such an exception across 3d party
code.)

The simplicity of Havoc's suggestions allow us to meet some of
the objections without falling over backwards to achieve the
impossible.

Tim Janik <timj@gtk.org> writes:

> On Fri, 3 Dec 1999, Havoc Pennington wrote:
> 
> >  - change the default handler to exit(1) instead of abort()
> 
> i don't think this is actually a good idea, we currently use g_error()
> to abort failing g_malloc()s which is the standard glib error handler
> and cares about putting the message somewhere, so programs that reroute
> stderr and/or stdout can still log stuff to a file.
> apart from that, g_malloc() can fail for allocations like ~(int)0
> which may be caused by int wraparounds or similar bugs in a program,
> in such cases you want a coredump or backtrace.
> since malloc() usually doesn't fail with ENOMEM it's a pretty minor
> portinon of core dumps you'd avoid anyways.

I think we absolutely must not coredump on any condition that
could be a system problem instead of our problem. We've gotten
bitten by this for XIOError(); the GNOME 1.0.0 desktop looked more
(OK even more) unstable than it really was, since when you
Ctrl-Alt-Backspaced your X server, every GTK+ program would
drop core.

If you want to maintain the use of g_log (as unlikely as that is
to work in out of memory conditions), then we need to add
an extra level of severity to the g_log() system ... fatal
but non-coredumping, and have a g_die() or g_warn_and_exit()
that logs at that severity.
 
> >  - add g_unchecked_malloc(), g_unchecked_realloc()
> 
> i'd rather call this g_try_malloc() to be consistent with other
> API calls in glib, e.g. g_quark_try_string().
> also, do we really need a g_try_realloc() variant there (or
> corresponding try_malloc0() try_new(), try_new0())?
> the rare cases where you allocate a memory region that huge that
> you better check whether you'd get it, should be handled fine by
> plain g_try_malloc().

I agree with Havoc, that we should go through the extra bother
and add a try_realloc() ... realloc() is simply not equivalent
to malloc().

Regards,
                                        Owen