Re: xmalloc string functions

ymuntyan@xxxxxxxxx wrote:

On Jan 28, 10:33 pm, Randy Howard <randyhow...@xxxxxxxxxxxxxxxxx>
wrote:
On Mon, 28 Jan 2008 17:30:50 -0600, ymunt...@xxxxxxxxx wrote
(in article
<03141a7b-0c59-4d73-af65-4f88da892...@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>):

On Jan 28, 1:39 pm, Flash Gordon <s...@xxxxxxxxxxxxxxxxxx> wrote:
No idea, ask the developers of that buggy application.
Failed fopen() is not an exceptional condition. Failed
malloc() is. Or we are using different vocabularies.

The point is that they both require similar recovery strategies.

The point is that they don't. If fopen() fails, there is nothing
to recover from.

False. If fopen() fails, it could have been because the user had a
typo in a filename he wanted to open in another window to cut/paste
from. When you bail out of the app because this file couldn't be
opened, that's just plain /stupid/. There are cases where a fopen()
failure could be critical with no possible way to recover, continue,
or retry, but they are rare.

There is nothing to recover because failure of fopen()
is a normal situation. Absolutely different from a failure
of malloc() when you are trying to allocate a structure
to push into the event queue to scroll text a bit later.

Though if all your application does is fopen(),
then you can safely abort() when fopen() fails.

Or, you could try and determine why it failed, and take corrective
action, either automatically, or at the user's direction. But hey,
that cuts into the Xbox360 time, eh?

Strawman you see. We were talking about malloc() and
you tell my application will crash when fopen() fails.

Note that if your application can ask user about something,
then it does more than fopen(). If it can take any
action when fopen() fails, then it does more. That's
what I meant. cat utility doesn't have much to do
if it can't open the file it's supposed to read.
A gui application doesn't have much to do if it
doesn't have memory to draw stuff it draws.

This is why a complex application needs more than one type of
out-of-memory handler. If a fairly large allocation fails, there is a
real chance that a much smaller allocation /can/ succeed, either for
continuing the program's usual work at a slower pace or to pop up a
message box for the user giving him the option of quitting or killing
some other program and retrying.

OTOH, if a small allocation, say a kilobyte or less, fails then we
probably have a serious resource crunch. There is /no/ point in
reducing the allocation size and trying again, nor is there much point
in trying to bring a dialogue box (though you can try). Probably a
sensible strategy is to attempt saving open files (which may or may not
succeed, but it won't hurt to try), attempt to log a message to stderr
or whatever and then exit with a error status.

But even in this severe case an abort() or a segfault or exiting
silently in a library routine is not a good strategy, IMHO.

<snip>

No, it's way better if the guy happens to have a dozen apps open at
the moment, and this one is really critical work that he's been
entering data into for the last 2 hours. You could do this:

Display a message to the effect of "Unable to add new record due to
an out of memory condition, please close some other applications if
you would like to try again, or save the work in progress to prevent
data loss"

BS. You can't display message if you don't have memory. You could
reserve some, specially for the message, and *try* to display it.
But it won't show up anyway.

Yes. This is why not all allocations in a program can meaningfully have
the same error handling logic. Some allocations may be totally
redundant. Say the program wants to draw a nice splash screen. If
allocation fails here, nothing needs to be done, the program still
attempt running. A splash screen is just eye-candy.

Similarly the program may try to allocate a large buffer for efficiency
and if this fails, it can try running with a much smaller buffer. Again
the error handling is different.

OTOH a failure of a few kilobytes is pretty big blow and the only
sensible thing is to try and log a message, try to close your files and
resources and exit.

Yes, this is work, but the other option is to respond uniformly and
unintelligently to each and every resource acquisition failure, always
terminating abruptly on the user. I have used many such applications
and they are a /big/ annoyance.

But instead, this /wonderfully/ designed application aborts and dumps
all his work.

It's not necessary to dump the user's work. On the contrary,
you should try to save his work if you can. But I'll be glad
to see what you would do in a dictionary application. Or in
an mp3 player. If you believe that an mp3 player shouldn't
abort when it can't allocate memory for a playlist, it's a
fine opinion, and you simply shouldn't use mp3 players
based on glib. Others still will (you know why? because
it won't abort)

No. An MP3 player can still run. Perhaps the stupid user tried to put
10000 titles into the playlist. Perhaps memory for this is unavailable
but enough memory is still available to continue running the current
track. As I said error handling depends (or should depend) intimately
on the exact contextual state of the application and it's environment.

A uniform strategy is hardly better than no error handling at all.

<snip>

If you check, it won't segfault. That's the whole point. You'll
detect an error, and handle it, instead of merrily trudging along and
counting on the runtime to abort your entire process so you don't
have to worry about branch prediction hits in your wonderfully
bloated, yet somehow pseudo-optimized pile of crap you foist on the
user community.

So, we got to crap finally. Good. Think what you do when you
next time run a shell, or python, or a perl script. Aren't you
afraid of using gui applications, by the way? Or can you
present an example of one which continues working after malloc()
fails? Source code please.

In the past I have used a 3D modelling application that would try to
continue the simulation under low memory conditions by turning off
other parts of the program and non-essential parts of the simulation
itself. For example it would switch off background and colour-filling
for the object.

Off course this is a case of a large allocation failure and not a
failure for a few hundred bytes, which would have been essentially
unrecoverable.

<snip>

.

Relevant Pages

  • Re: When to check the return value of malloc
    ... code to handle the failure of every single allocation. ... most of the time the program will fail to get memory again ... meanwhile the app may be able to do other useful things. ... In other cases - such as the one I mentioned - an allocation failure is ...
    (comp.lang.c)
  • Re: xmalloc string functions
    ... than a NULL return from malloc(). ... Memory is quite a different kind of resource. ... I try to write my code so any allocation failure is handled ... its not likely that one will be more susceptible to failure than the other. ...
    (comp.lang.c)
  • Re: A solution for the allocation failures problem
    ... reduce the effort involved in managing memory. ... Releasing such buffer may not effect the ability of malloc() to return ... says it releases the memory for subsequent allocation, ... Dealing with the failure "at point of failure" isn't inherently evil. ...
    (comp.lang.c)
  • PROBLEM: unchecked returns from kmalloc() in linux-2.6.10-rc2
    ... Checking whether memory allocation succeeded is important, ... Failure might cause a kernel crash. ... the return from kmalloc() is validated before ... Here, memory is allocated for pcpu_size on line 335, and then ...
    (Linux-Kernel)
  • Re: xmalloc string functions
    ... than a NULL return from malloc(). ... Or I can use the debugger to put a breakpoint in and change the pointer value to null at the point I want to trigger the failure. ... Memory is quite a different kind of resource. ... I try to write my code so any allocation failure is handled ...
    (comp.lang.c)