Re: xmalloc string functions

William Ahern wrote:
Yevgen Muntyan <muntyan@xxxxxxxxxxxxxxxxxxx> wrote:
<snip>
I'd think evolution crashed because it crashed. You can look at
its list of bugs to see what I mean. If it was abort() inside
g_malloc(), then it probably leaked so much that it indeed has
eaten everything and asked for more. In which case you can't
really blame glib ;)

Actually, it was usually Galeon/Gecko which leaked, or rather whose leaks
would begin to trigger out-of-memory errors. But that's beside the point.
I'd much rather that Evolution fail to open a message than to exit entirely.

(Here I'd be actually grateful if such applications were killed
immediately, because they first freeze X, and I've got to wait
for ten minutes to switch to console and kill the application.
They just don't die themselves.)

If these were the only choices (crashing applications or a frozen screen),
I'd be more agreeable.

There were many bad spots in Evolution, but mostly the code was OK (I've
combed through much of it). Evolution had to deal with bad UTF encodings,
malformed MIME, networks coming up and going down. Handling memory
allocation failures would hardly add much in the way of complexity or
effort.

[snip]

The problem is that such a strategy is usually the wrong one for the class
of applications which glib serves: desktop applications, and increasingly
network daemon services. Both of those usually involve monolithic
applications doing complex tasks for which memory allocation failure is only
one of dozens or hundreds of exceptional conditions.

This is very very wrong. A typical GUI application does not do a
switch like

switch (problem_to_handle)
{
....
}

to which you could add

case ALLOC_FAILED:

It's usually different, you got the main loop which
got to spin, you got those controls you got to draw,
and you got those callbacks which actually do the
job. And the callbacks do one thing at a time, they
do not handle dozens of exceptional conditions at once,
they do not handle exceptional conditions at all
in fact.

And yet out of all of
them people will argue memory allocation alone can be completely ignored,
simply because it's too burdensome.

No, because the effort would be gigantic, you would still fail to
do it properly, and at the end it would bring no benefit.

How would you test it? Imagine a toolkit which doesn't abort
on memory allocation failure: why would you have a slightest
reason to believe that given application won't just segfault
on malloc() failure? (The question which applies to all
applications which do try to handle malloc failure of course).
What you can be sure about is that there would be more chances
for an application to screw up and actually corrupt your data
or display wrong data.

All you can sensibly do on malloc() failure is to kill the
application. Maybe save the data you can save or something
(which you can do with glib). What else? Say, if malloc() failed
when the main loop code tries to process an event from Xlib, it
can start fail silently, it can be killed by an x error because
it failed to take into account some data it got (timestamp?),
it can grab the mouse and lock the X server, it can do many
other nasty things I can't make up right now.

Or, if malloc() failed when you tried to show a dialog telling
the user he got to call his mama, he won't call his mama! (Yes,
if the application crashed, the user will restart it, see the
dialog, and call his mama, users are like that. Those users who
are lucky enough to see an application aborting because memory
allocation failed. Randy Howard, you, and perhaps few other
people from comp.lang.c ;)

Of course I am talking about "small" allocations here, not
about stuff like allocating memory to load an image file (for
those g_malloc() is simply not used).

Perhaps in ideal world with ideal toolkits things would
be different, don't know about that. But I do know that
while dumb abort() is not the best possible solution,
talking about how it is easy to do things differently is
just a child talk. "Of course I would do it better!" Yeah.

Regards,
Yevgen
.

Relevant Pages

  • Re: Policy on rebooting?
    ... > was that if you're doing dynamic memory allocation, ... I am disagreeing with "isn't a good idea". ... > memory allocation in an environment with 256 bytes is a good idea. ... basically disagreeing with the 'never malloc on Sunday' mantra. ...
    (comp.arch.embedded)
  • Re: Any way to speed up "new"?
    ... > From my tests I deduce that a considerable part of the computational ... > time is spent on the memory allocation, ... So using new is slower than using malloc? ...
    (comp.lang.cpp)
  • Re: xmalloc string functions
    ... allocation failure is a critical issue. ... Another app, failure to open the file may be fatal. ... Stack space is also such a resource. ...
    (comp.lang.c)
  • Re: static memory allocation versus dynamic memory allocation
    ... static memory allocation instead of dynamic memory allocation. ... refer to dynamically allocated space is through a pointer. ...
    (comp.lang.c)
  • Re: Bug in MFC CList?
    ... Compilers do not manage memory allocation; ... exponential allocation algorithm. ... overhead...perhaps an order of magnitude greater than the loop cost. ...
    (microsoft.public.vc.mfc)