Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > A solution for the allocation failures problem

Reply
Thread Tools

A solution for the allocation failures problem

 
 
santosh
Guest
Posts: n/a
 
      01-29-2008
Richard Tobin wrote:

> In article <fnn3og$o40$(E-Mail Removed)>, jacob navia <(E-Mail Removed)>
> wrote:
>
>>It is not possible to check EVERY malloc result within complex
>>software.

>
> I assume you're just setting up a scenario here rather than making
> this claim yourself.
>
>>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.

>
> This is not guaranteed to help with all malloc() implementations.
> Some use different areas of memory for different sized blocks, and may
> not have code to re-purpose the freed block. Or they may free the
> memory back to the OS, in which case it may get gobbled up by
> something else before they have the chance to re-use it.


Yes. A better strategy is to use this buffer directly. No need to invoke
all the uncertainty involved in freeing and allocating again.

 
Reply With Quote
 
 
 
 
Malcolm McLean
Guest
Posts: n/a
 
      01-29-2008

"jacob navia" <(E-Mail Removed)> wrote in message
> 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.
>

xmalloc() calls a caller-defined emergency function. It can do several
things, one of which is to simply exit. Don't confuse the requirement to
return the memory requested or (inherently) abort with the requirement to
abort.

--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm

 
Reply With Quote
 
 
 
 
Bartc
Guest
Posts: n/a
 
      01-29-2008
jacob navia wrote:

>A solution for the allocation failures problem


You may have noticed this is somewhat controversial here. Doubt you will get
much agreement. It's one of those things where everyone has their own ideas.

--
Bart


 
Reply With Quote
 
Eric Sosman
Guest
Posts: n/a
 
      01-29-2008
jacob navia wrote:
> 1:
> It is not possible to check EVERY malloc result within complex software.


Why not? It's no harder than checking every fopen() for
success -- or is that another impossibility?

> 2:
> The reasonable solution (use a garbage collector) is not possible for
> whatever reasons.


Garbage collection (when it works) eases the memory management
problem by relieving the programmer of the need to call free().
But collecting all the garbage does not imply that every malloc()
will succeed! In fact, a collector that cannot relocate the non-
garbage is likely to increase fragmentation and produce allocation
failures when a free()-as-soon-as-possible strategy would not.

> 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.


This is a reasonable thing to try, and has been tried
often. The hard part is choosing a value for "big:" too little
and there's not enough for the cleanup activity, too much and
you provoke allocation failures that don't need to happen.

> 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.


The problems of longjmp() are well understood. It's possible
to use it effectively, but the programmers who write functions
"between" the setjmp() and the longjmp() must be constantly aware
that they might not get a chance to clean up:

char *this = dup(getenv("THIS"));
char *that = dup(getenv("THAT"));
printf ("THIS = %s, THAT = %s\n", this, that);
free (this);
free (that);

See the memory leak? If the second dup() eventually calls
longjmp() and returns to an ancestor of this code, the
memory allocated to `this' is never freed.

It's possible to work around this problem: various people
have put together macro packages that imitate a try/finally
discipline, for example. But the language itself gives little
help, and the compilers won't warn if somebody forgets (for
example, when a function that originally didn't need cleanup
acquires such a need during maintenance). Error recovery
based on longjmp() is do-able, but difficult.

--
http://www.velocityreviews.com/forums/(E-Mail Removed)
 
Reply With Quote
 
Keith Thompson
Guest
Posts: n/a
 
      01-29-2008
jacob navia <(E-Mail Removed)> writes:
> 1:
> It is not possible to check EVERY malloc result within complex software.

[...]

It's not only possible, it's required.

--
Keith Thompson (The_Other_Keith) <(E-Mail Removed)>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
 
Reply With Quote
 
Serve Laurijssen
Guest
Posts: n/a
 
      01-29-2008

"Richard Bos" <(E-Mail Removed)> schreef in bericht
news:(E-Mail Removed)4all.nl...
> jacob navia <(E-Mail Removed)> wrote:
>
>> 1:
>> It is not possible to check EVERY malloc result within complex software.

>
> *******s from the start. Well done.
>
> Richard


Think he meant it's not possible to HANDLE every malloc failure. Indeed its
pretty easy putting an if in there, but not so easy to actually gracefully
handle it.

 
Reply With Quote
 
Keith Thompson
Guest
Posts: n/a
 
      01-29-2008
"Serve Laurijssen" <(E-Mail Removed)> writes:
> "Richard Bos" <(E-Mail Removed)> schreef in bericht
> news:(E-Mail Removed)4all.nl...
>> jacob navia <(E-Mail Removed)> wrote:
>>
>>> 1:
>>> It is not possible to check EVERY malloc result within complex software.

>>
>> *******s from the start. Well done.

>
> Think he meant it's not possible to HANDLE every malloc
> failure. Indeed its pretty easy putting an if in there, but not so
> easy to actually gracefully handle it.


Yeah, programming is hard.

--
Keith Thompson (The_Other_Keith) <(E-Mail Removed)>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
 
Reply With Quote
 
William Ahern
Guest
Posts: n/a
 
      01-29-2008
Serve Laurijssen <(E-Mail Removed)> wrote:

> "Richard Bos" <(E-Mail Removed)> schreef in bericht
> news:(E-Mail Removed)4all.nl...
> > jacob navia <(E-Mail Removed)> wrote:
> >
> >> 1:
> >> It is not possible to check EVERY malloc result within complex software.

> >
> > *******s from the start. Well done.
> >
> > Richard


> Think he meant it's not possible to HANDLE every malloc failure. Indeed its
> pretty easy putting an if in there, but not so easy to actually gracefully
> handle it.


If you write software not intending to recover from a malloc failure, then,
yes, upon inspection your code will prove to be very difficult to modify to
handle such recovery.

But, that's beside the point. If at outset you write your code intending to
handle recovery, its not difficult at all. I don't remember (and granted I
can't remember what I wrote when I first began programming in C) ever being
in a situation where I found it difficult to recover or unwind from a path
because of a failed malloc call. Of course, I have developed a very
structured, almost rote method for writing software which suits me. But I
did so by necessity, because from very early on I never accepted the premise
that memory failure could or should be ignored.

I originally learned to program with Perl, then JavaScript (Navigator 3.0).
Subsequently, to me memory management was a _feature_. I found it much more
satisfying to have the capacity (if not perfectly realized or utilized) to
write more resilient programs.

When I don't wish to exercise that feature, and if C is otherwise not
particularly suited to a task, I use another language.

Aside from glib, I can't off-hand think of any widely used Free Software C
library which doesn't check and propogate memory allocation failures.

 
Reply With Quote
 
Malcolm McLean
Guest
Posts: n/a
 
      01-29-2008

"William Ahern" <william@wilbur.25thandClement.com> wrote in message
> But, that's beside the point. If at outset you write your code intending
> to
> handle recovery, its not difficult at all. I don't remember (and granted I
> can't remember what I wrote when I first began programming in C) ever
> being in a situation where I found it difficult to recover or unwind from
> a
> path because of a failed malloc call. Of course, I have developed a very
> structured, almost rote method for writing software which suits me. But I
> did so by necessity, because from very early on I never accepted the
> premise that memory failure could or should be ignored.
>

I wrote xmalloc() for Baby X, which is a minimalist X windows toolkit.
The problem is that the whole IDE is strung together with function pointers,
so there is no high level to propagate to. Most of the allocations are for
tiny structures associated with windows, anyway. It is also not clear what
you should do if unable to put up a window. My solution is to nag the user
for more memory until he gives it or kills the application.

--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm


 
Reply With Quote
 
Jack Klein
Guest
Posts: n/a
 
      01-29-2008
On Tue, 29 Jan 2008 12:47:27 +0100, jacob navia <(E-Mail Removed)>
wrote in comp.lang.c:

> 1:
> It is not possible to check EVERY malloc result within complex software.


Yes, it is. Poor programmers might not wish to do so, and might
produce arguments defending their choice, but that does not change the
fact that it is possible.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://c-faq.com/
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.club.cc.cmu.edu/~ajo/docs/FAQ-acllc.html
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
An idea for heap allocation at near stack allocation speed Bjarke Hammersholt Roune C++ 14 03-06-2011 08:07 AM
Handling allocation failures? Richard Tobin C Programming 7 09-29-2007 07:25 AM
static memory allocation versus dynamic memory allocation Ken C Programming 24 11-30-2006 12:37 AM
What is the difference between dynamic memory allocation,and stack allocation ? chris C++ 6 10-28-2005 05:27 AM
WLAN driver failures after re-install =?Utf-8?B?Sm9uIEdyZWVu?= Wireless Networking 0 08-24-2005 10:08 AM



Advertisments