W
William Ahern
Yevgen Muntyan said: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.
There is no xmalloc() wrapper in glib. Anyway, have you never
seen "mostly working" application which do not use glib? Bugs
are everywhere, on all platforms. Do you have a real base for
saying that g_malloc() is somehow responsible for crashes you
have seen? Something other than "evolution crashed", that is,
or "similar applications" (similar glib-based applications
which open messages, huh?).
I know for a fact that Evolution and similar applications have exited
because their malloc wrapper decided to exit. They've also crashed for
numerous other reasons. Bugs are bugs, but defective by design is hardly
excusable.
Exiting on malloc failure makes sense for a utility like sort(1). It doesn't
make sense for desktop applications, unless there's a separate strategy,
like a multi-process configuration where a component exiting is part of the
design of handling errors and making a best-effort recovery.
It makes sense for sort(1) because it categorically cannot perform its task
on a failure. And its practical because sort is usually just a sub-component
in a larger work. Sort can exit without killing the script or application
which called it.
You know, I have heard things like you are saying only from
people who talk about xmalloc() and related things. Never from
users. Why is that? Perhaps because buggy applications are
buggy applications, not some poor creatures crashing because
glib memory handling is broken?
Users are, sadly, inured to this issue. Nor can they discern the reason for
failure, so they aren't capable of judging the cost/benefit of any
particular behavior.
You sort of missed part of my point regarding Evolution. What I was
experiencing was a denial of service caused by processing untrusted data.
And by using glib you have no recourse. Indeed, much of glib's functionality
is simply a rehash of, by now, widely supported library interfaces, but with
the feature of exiting when memory becomes tight.
It's fine, nobody promiced glib will work for any program. It certainly
won't; but nevertheless it doesn't make abort-on-failing-malloc less
sensible strategy for a whole class of applications.
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. And yet out of all of
them people will argue memory allocation alone can be completely ignored,
simply because it's too burdensome.
Besides, a glib application can set up some sort of emergency memory
pool or something, so that failed malloc doesn't necessarily lead to
immediate abort(). Same sort of science fiction as "graceful exit with
saving data on *any* failed malloc() call in any possible application
in any possible situation" which seems to be so popular here
It's not science fiction. It's just difficult. And sometimes the answer
involves not using C, rather than using C and choosing not to address the
problem.