This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: malloc problem/question in 2.1.3


Do you do any XWindows programming???  One of the more
common and hard to track down problems are SIGSEGV's
caused by inadvertently freeing memory that was not previously

char* ptr = NULL ;

if (ptr != NULL) {
   free(ptr) ;
   ptr = NULL ;

This makes sure you don't inadvertently free memory not previously

It's quite common to define pointers and then use malloc to
allocate at runtime only the memory needed to display an image.
If it's a photo display program, many different sized images may
be displayed in one program and the same pointer to the image
data would be free'd and re-allocated for each new image selected.

Kathy Bieltz

Mike Corbeil wrote:

> Ronald de Man wrote:
> > On Sat, Jun 03, 2000 at 07:13:51PM -0400, Mike Corbeil wrote:
> > > Ronald de Man wrote:
> > >
> > > > On Fri, Jun 02, 2000 at 07:45:34PM -0400, Mike Corbeil wrote:
> > > > > Wolfgang Sourdeau wrote:
> > > > >
> > > > > >     Mike> As a short aside, I think that this could be checked for in
> > > > > >     Mike> Perl using "defined" (e.g., if defined $var ...), however C
> > > > > >     Mike> is a compiled language and I don't think there's any such
> > > > > >     Mike> functionality, not afaik anyway.
> > > > > >
> > > > > > One could implement this by writing a wrapper for malloc and free
> > > > > > which would do the accounting. Another way to do that is to put a
> > > > > > pointer to NULL directly after it is freed and it is even easier. Be
> > > > > > careful though to make this coherent with the whole code.
> > > > >
> > > > > If a job must be done in C and such functionality is desired, then a
> > > > > wrapper is probably an acceptable solution.  I've used and created
> > > > > wrappers before, however thought the programmer wanted built-in
> > > > > functionality, and wrappers are an elementary concept, but not
> > > > > built-ins.  (Wrapping is actually, conceptually, inherent in all
> > > > > programs using functions or procedures, and a program itself is a
> > > > > wrapper, albeit neither is the kind of wrapper Wolfgang referred to.)  A
> > > > > wrapper is certainly an easy approach.
> > > > >
> > > > > However, I'm not sure what is meant by "put a pointer to NULL" after it
> > > > > is freed.
> > > >
> > > > char *ptr = (char *)malloc(100);
> > > >
> > > > /* use the 100 allocated bytes */
> > > >
> > > > free(ptr);
> > > > ptr = NULL;    /* put ptr to NULL */
> > >
> > > I assumed this was what you meant, but this is unnecessary, unless ptr is
> > > going to be used again.  One simple case to show how this is, simply is that
> > > free is often called at the end of functions.  However, even when called
> > > before the end of a function, there's no logical reason to do this, because
> > > the pointer was just freed.
> >
> > The point is that one can now check whether the pointer is still valid
> > by testing it against the NULL value.
> I understood that, but there's no logical reason for it, except like you say to
> potentially hide bugs, or poor C programming.  You probably won't find a good,
> authoritative, book on programming in C which instructs people to redefine the
> pointer to null after the pointer's been freed, or at least I've never come
> across such a  book.
> Perhaps there are programs in which this would be applicable, however no one has
> mentioned any examples, yet.
> > This is a way to improve robustness
> > of the program. (On the other hand it might hide bugs.)
> Should have no impact wrt improving robustness.  If we did this for every piece
> of code where such a concept could possibly or potentially apply, then yuck is
> about all I could think of.  We need more reliability than that, imo.
> > This discussion was about the perceived lack of robustness in free().
> It's not really only perceived; it's real, but it's also known and a known is
> always better than an unknown.  It's been known for longer than I've known C,
> since June 89 (I had merely forgotten the reason); however, no expert has ever
> suggested that a free'd pointer be immediately redefined to null, for robustness
> or any other reason, and I agree with them in excluding this nonsense as well as
> believe that it's nonsense, usually anyway, except when necessary and only
> context will be the decisive factor.
> > For example, programs tend to crash when free()ing memory twice.
> Just don't do that.  Proper logic should preclude this, I believe.  Otoh, perhaps
> it would be proper logic, but we haven't been provided with any real world
> examples, so far.
> > Wolfgang pointed out that one common way to prevent this type of
> > crashes, is to set a pointer to NULL when it is no longer needed.
> >
> Should not need to be done, at least not in well designed and written programs.
> Again, there may be examples where this is indeed applicable, however these
> examples haven't been mentioned.   We need applicable, real world, examples; or
> at least I do, to be convinced.
> > My example could have been clearer:
> >
> > if (ptr != NULL) {      /* is this a valid reference? */
> >   free(ptr);            /* then we can free the memory */
> >   ptr = NULL;
> > }
> Comments are unnecessary for me, because I know C; however, the last statement is
> or at least should be unnecessary.  If it's necessary, then this indicates that
> there's another problem and it should be resolved by other means, like clean
> programming; or, it's an application-specific need, in which case what's the
> example would be my question.
> > If the memory block had already been freed (so by convention, ptr had
> > been set to NULL), then this check makes sure it is not freed for a
> > second time.
> That's only wrt the 'if' check, which isn't at all what I was questioning.  This
> I have no question about wrt C, because it's basically imposed by or in C.
> It's not technically or strictly valid wrt redefining the ptr to null, which is
> what I was questioning.  I might initialize a ptr to null prior to calling malloc
> or calloc, or where a ptr is declared (where I always init to null, or what ever
> the default value is to be), however to say that this should be done every time
> free has been called is not necessary, afaik.
> In the case of the if (in C), the programmer is doing what free should do;
> however, historically, there was a performance impact (had forgotten the reason,
> but knew there was one); therefore, free wasn't written to check for this
> condition.  This problem or caveat, however, has surely disappeared with the dawn
> of more powerful CPUs, and ANSI isn't robust, except at a superficial level (ANSI
> sucks, in this sense, #$#$#$#$!!!!!, as I'm sure many would say, more or less).
> Redefining ptr to null is a very separate, distinct, concept, because it really
> has nothing to do with free, except that free doesn't make the redefinition.
> Although free could do this, there's really no reason for it to do so and there
> are cases where this would be unnecessary overhead, technically and logically.
> Checking the ptr before calling free is kind of a patch, as is redefining ptr to
> null, but only the first or former patch is logically valid, in a strict sense,
> but only because it's imposed by C or $#$!@#$!@#!!!! ANSI.
> > >
> > > > >
> > > > > Do you mean to redefine the pointer as the null string, as it would be
> > > > > done in the initialization of a pointer, and if yes, then why would one
> > > > > want to do this immediately after calling free, when free is supposed to
> > > > > free the memory previously reserved for the pointer, after which such a
> > > > > pointer typically isn't used, at least not until malloc is to be invoked
> > > > > again for the pointer?
> >
> > [I am sorry to have disturbed you, but reading the above did give me
> > the impression that you were mixing up pointers with the memory
> > blocks pointed at by pointers.]
> No problem.  If you honestly misinterpreted my knowledge of C, then that's
> human(e), and because C has been ported to most platforms, I'm not expert in all
> respects.  I wanted to make sure people understood that I'm not new to C;
> programmed with C since 89, took a very good course on C, and have read several
> good books from industry reknowned experts on C, over the years, as well as
> having developed in C and maintained an ample number of C programs.
> This, however, does not mean that I'm absolutely correct.  I'm not GOD.  It's
> possible that redefining the pointer to null is necessary in some cases, however
> I've never come across any such cases, and no examples have been provided, here,
> so far.
> For example, in some contexts it's crucial or important to check the result of
> malloc, but in others, like VAX/VMS, it's not necessary, or at least not
> according to some people who developed mission critical systems in C on this
> platform; people possessing graduate degrees in CS.  I believe that it is
> unnecessary in VAX/VMS, but it is definitely a strong plus or even necessary in
> MS, or at least MS DOS.  For Unix I'm not sure, however regardless what OS I
> program in, I always check the result of malloc, even if only for potential
> portability.
> > Note that on the internet it is common practice to refer
> > people to more appropriate forums. This list is intended for
> > discussion of the use of the GNU C library.
> I understand that.  However, I try to be flexible and believe that there's plenty
> of room on the internet for this.
> As long as meaningful Subject titles are used, then I'm happy.  I have no problem
> reading a subject title and deleting the mail if I'm not interested; letting
> others get on with their business while I get on with mine; an independent minded
> squirt I am.  Besides, it's virtually imposssible to monitor the internet to 100%
> exactness.
> I'm exacting wrt programming computers, because they only do what they're
> instructed to do, but when it comes to humans, flexibility is fine with me.   You
> have plenty of room with me and I also firmly, thoroughly, believe in sharing
> knowledge, a grand concept imo.
> In this case, the original question was accepted and once that happens, I let the
> river flow, without trying to impede it, because it encourages learning, which
> all humans benefit from, eventually, one way or another, etc.   The subject title
> is what I rely on.
> Also, there are too many truly important contentions and disagreements in this
> world for me to waste energy needlessly.
> Thank you.  I appreciate your reply, cool and calm, merci beaucoup.
> If I'm still off on usage, then please feel free to reply.  I'll consider input,
> even if the above kind of flexiblity is the way I prefer to look at life.  Maybe
> I need to be cemented, a little, but I like flexible.
> Mike

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]