This is the mail archive of the
glibc-linux@ricardo.ecn.wfu.edu
mailing list for the glibc project.
Re: malloc problem/question in 2.1.3
- To: glibc-linux at ricardo dot ecn dot wfu dot edu
- Subject: Re: malloc problem/question in 2.1.3
- From: Kathy Bieltz <kbieltz at hal-pc dot org>
- Date: Mon, 05 Jun 2000 14:28:56 -0500
- References: <Pine.LNX.4.10.10006050939410.5936-100000@ashi.FootPrints.net>
- Reply-To: glibc-linux at ricardo dot ecn dot wfu dot edu
Kaz,
Kaz Kylheku wrote:
> On Mon, 5 Jun 2000, Kathy Bieltz wrote:
>
> > Date: Mon, 05 Jun 2000 08:31:50 -0500
> > From: Kathy Bieltz <kbieltz@hal-pc.org>
> > Reply-To: glibc-linux@ricardo.ecn.wfu.edu
> > To: glibc-linux@ricardo.ecn.wfu.edu
> > Subject: Re: malloc problem/question in 2.1.3
> >
> > Mike,
> >
> > 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
> > allocated.
>
> This simply means that you have bungled your logic for initializing and
> destroying subsystems and objects. This could be the result of poor planning
> at the design stage.
>
Or you could be debugging legacy XWindow code developed by
a programmer who has left for a project already overdue without
the benefit of tools like Electric Fence.
>
> > char* ptr = NULL ;
> >
> > if (ptr != NULL) {
> > free(ptr) ;
> > ptr = NULL ;
> > }
>
> This is not necessary. Calling free on a null pointer is permitted by ANSI C.
> Look it up in your library reference manual. So you could just write:
Not all the platforms the code I port to use ANSI C compilers. We're
trying to phase out support for those platforms so I might be able to
take advantage of this in the future.
>
>
> free(ptr);
> ptr = NULL;
>
> > This makes sure you don't inadvertently free memory not previously
> > allocated.
> The problem with doing this solely for the purpose of trying to prevent bugs is
> that it may incapacitate the effectiveness of tools that are designed to find
> the problem, such as ElectricFence. By turning undefined behavior (calling free
> on an indeterminate pointer) into well-defined behavior (calling free on a null
> pointer) you may mask the bug, making it harder to pinpoint when the invalid
> second call to free took place. You will have to work backwards from the
> failed use of the null pointer to deduce out how it got that way
>
> > 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.
>
> That's a special case; you have a short lived object, with a possible state of
> ``not present'' which needs to be indicated by a null value of the pointer, or
> some other thing; the null value is necessary to the logic.
I guess I work with alot of special case code since my programs read in
a lot of different kinds of data with a variable size.
Kathy Bieltz