Re: A solution for the allocation failures problem
- From: "Herbert Rosenau" <os2guy@xxxxxxxxxxxxx>
- Date: Wed, 6 Feb 2008 09:19:54 +0000 (UTC)
On Tue, 29 Jan 2008 11:47:27 UTC, jacob navia <jacob@xxxxxxxxxx>
wrote:
1:
It is not possible to check EVERY malloc result within complex software.
This is a lie!
2:
The reasonable solution (use a garbage collector) is not possible for
whatever reasons.
Where in the standard is a garbidge collector mentioned?
3:
A solution like the one proposed by Mr McLean (aborting) is not
possible for software quality reasons. The program must decide
if it is possible to just abort() or not.
Solution:
1) At program start, allocate a big buffer that is not used
elsewhere in the program. This big buffer will be freed when
a memory exhaustion situation arises, to give enough memory
to the error reporting routines to close files, or otherwise
do housekeeping chores.
Releasing such buffer may not effect the ability of malloc() to return
or not memory at all.
2) xmalloc()
static int (*mallocfailedHandler)(int);
void *xmalloc(size_t nbytes)
{
restart:
void *r = malloc(nbytes);
if (r)
return r;
// Memory exhaustion situation.
// Release some memory to the malloc/free system.
if (BigUnusedBuffer)
free(BigUnusedBuffer);
BigUnusedBuffer = NULL;
if (mallocfailedHandler == NULL) {
// The handler has not been set. This means
// this application does not care about this
// situation. We exit.
fprintf(stderr,
"Allocation failure of %u bytes\n",
nbytes);
fprintf(stderr,"Program exit\n");
Who says that the application is able to print to stdout? Any GUI app
on my OS has neither stdin, stdout nor stderr pointing to something
known as (virtual) device.
exit(EXIT_FAILURE);
}
// The malloc handler has been set. Call it.
if (mallocfailedHandler(nbytes)) {
goto restart;
}
// The handler failed to solve the problem.
// Exit without any messages.
exit(EXIT_FAILURE);
}
Crappy because a simple return NULL to the caller of the function
calling malloc() is the only manageable solution to recover from that
failture as only the caller or its caller will be able to win enough
memory to continue successfully.
4:
Using the above solution the application can abort if needed, or
make a long jump to a recovery point, where the program can continue.
No, it can not because loss of human life, loss of other goods may be
the consequence of simpy exit(). The only who knows to handle the
unabiltity of malloc() is the caller or its parent of malloc().
The recovery handler is supposed to free memory, and reallocate the
BigUnusedBuffer, that has been set to NULL;
No, as the exactly one useable recovery handler is only rechable
through the return chain of the calling sequence ending with seeing
out of memory.
exit() is forbidden because it will left much devices in an unmaintend
state, like
switches open, signals set, pumps pumping, rockets firing, gates
opened, filters passing, firing the 3. WWW up, .....
And all that because the programmer was to braindead to write a single
if.
Anything that can fail will fail. Ctch it and do the appropiate action
on the failture. You'll save howers over howers on maintenance, save
month on consts on stallstind of the factory, work, mashines, .....
only because the braindead programmer was too fishy to mak his error
checking right.
--
Tschau/Bye
Herbert
Visit http://www.ecomstation.de the home of german eComStation
eComStation 1.2R Deutsch ist da!
.
- Follow-Ups:
- Re: A solution for the allocation failures problem
- From: Bartc
- Re: A solution for the allocation failures problem
- From: Kelsey Bjarnason
- Re: A solution for the allocation failures problem
- Prev by Date: Re: Neatest way to get the end pointer?
- Next by Date: Re: "sorting the news"
- Previous by thread: Re: A solution for the allocation failures problem
- Next by thread: Re: A solution for the allocation failures problem
- Index(es):
Relevant Pages
|
