free()'ing problems 
Author Message
 free()'ing problems

Ok, let's start with I've read the fm and also the faq for this group.
I've also had experience with memory/malloc problems before.  Now
I'm getting something else weird that I hope someone can help me
solve:

I determined that I'm having problems and finally found that the
problem was in free()'ing previously allocated space.  Normally, this
would be either 1) I mis-allocated something, or 2) I'm not freeing
the right things.  Neither of those two answers APPEARS to be correct.
ASSUMING that I haven't made either of those two errors, what else
could it be?

As an example, here is one of my malloc statements:

    if((buf=(float *)malloc((i2 - i1 +1)*(j2 - j1 +1)*sizeof(float)))
            ==NULL)
            ...

and the associated free:

/*    free((char *)buf);  */
        ...

It is commented out b/c the program works that way!

Of course, I've included <malloc.h> and the other variables are
declared appropriately.

IF you can't answer the above question (or if I've made some error
that I told you I didn't make...), here is another:

Except for possible memory allocation problems later in the program,
is there anything wrong with not free()ing up memory?  I assume all
goes back when the program finishes?  I'm just wanting to make sure
that my kludge doesn't have any hidden dangers.

Thanks for any help.


Jim Klavetter
Physics and Astronomy
CSUS



Sat, 22 Feb 1997 05:48:37 GMT  
 free()'ing problems


Quote:
>    if((buf=(float *)malloc((i2 - i1 +1)*(j2 - j1 +1)*sizeof(float)))
>            ==NULL)
>            ...

>and the associated free:

>/*    free((char *)buf);  */
>        ...

>It is commented out b/c the program works that way!

>Of course, I've included <malloc.h> and the other variables are
>declared appropriately.

We can only take your word on that. If the variables used in the malloc call
have reasonable values then there is nothing wrong with the code you give.

What would be more useful would be an example of how you use the object
you allocated. Problems such as this are most often caused by a program
writing beyond the bounds of an allocated object and therefore corrupting
the stack.

Quote:
>Except for possible memory allocation problems later in the program,
>is there anything wrong with not free()ing up memory?  I assume all
>goes back when the program finishes?  I'm just wanting to make sure
>that my kludge doesn't have any hidden dangers.

There isn't anything wrong in the sense that most C implementations will
deallocate the entire memory used by a program, including its heap, when
it terminates.

--
-----------------------------------------


-----------------------------------------



Sat, 22 Feb 1997 20:09:53 GMT  
 free()'ing problems

: I determined that I'm having problems and finally found that the
: problem was in free()'ing previously allocated space.  Normally, this
: would be either 1) I mis-allocated something, or 2) I'm not freeing
: the right things.  Neither of those two answers APPEARS to be correct.
: ASSUMING that I haven't made either of those two errors, what else
: could it be?

  Why deal with what APPEARS and is ASSUMING.  What is the size of
  the malloc requested? What is the address returned by malloc?  What
  is the address being freed?  

--
_______________________________________________________________________


_______________________________________________________________________



Sun, 23 Feb 1997 22:56:41 GMT  
 free()'ing problems

Quote:

>Ok, let's start with I've read the fm and also the faq for this group.
>I've also had experience with memory/malloc problems before.  Now
>I'm getting something else weird that I hope someone can help me
>solve:

>I determined that I'm having problems and finally found that the
>problem was in free()'ing previously allocated space.  Normally, this
>would be either 1) I mis-allocated something, or 2) I'm not freeing
>the right things.  Neither of those two answers APPEARS to be correct.
>ASSUMING that I haven't made either of those two errors, what else
>could it be?

>As an example, here is one of my malloc statements:

>    if((buf=(float *)malloc((i2 - i1 +1)*(j2 - j1 +1)*sizeof(float)))
>            ==NULL)
>            ...

>and the associated free:

>/*    free((char *)buf);  */
>        ...

Why free it as (char *) when allocating it as (float *)?  You maybe running
into some kind of boundary alignment problem.  Try freeing it as a
(float *).

Quote:
>It is commented out b/c the program works that way!

>Of course, I've included <malloc.h> and the other variables are
>declared appropriately.

>IF you can't answer the above question (or if I've made some error
>that I told you I didn't make...), here is another:

>Except for possible memory allocation problems later in the program,
>is there anything wrong with not free()ing up memory?  I assume all
>goes back when the program finishes?  I'm just wanting to make sure
>that my kludge doesn't have any hidden dangers.

I can't say for sure, but I think this is a compiler dependency.

Quote:
>Thanks for any help.


>Jim Klavetter
>Physics and Astronomy
>CSUS

Dave


Mon, 24 Feb 1997 01:58:35 GMT  
 free()'ing problems


Quote:

> Klavetter) says:
>>As an example, here is one of my malloc statements:

>>    if((buf=(float *)malloc((i2 - i1 +1)*(j2 - j1 +1)*sizeof(float)))
>>            ==NULL)
>>            ...

>>and the associated free:

>>/*    free((char *)buf);  */
>>        ...

>Why free it as (char *) when allocating it as (float *)?  You maybe running
>into some kind of boundary alignment problem.  Try freeing it as a
>(float *).

Sooner or later the pointer has to be converted into the type that free
requires for its argument. For old compilers/libraries that was char *,
for ANSI systems it is void *. Some pre-ANSI systems may have required the
cast to suppress warnings or supply the correct type to the (unprototyped)
function. No cast is required in ANSI but it is harmless in this case
since ANSI guarantees char * is to have the same representation as void *.

--
-----------------------------------------


-----------------------------------------



Tue, 25 Feb 1997 21:10:23 GMT  
 free()'ing problems

Quote:


>> I determined that I'm having problems and finally found that the
>> problem was in free()'ing previously allocated space...

>> As an example, here is one of my malloc statements:

>>    if((buf=(float *)malloc((i2 - i1 +1)*(j2 - j1 +1)*sizeof(float)))
>>            ==NULL)

>> and the associated free:

>> /*    free((char *)buf);  */

> Why free it as (char *) when allocating it as (float *)?  You maybe running
> into some kind of boundary alignment problem.  Try freeing it as a
> (float *).

I haven't followed this thread, and I can't see right away what
Jim's problem is, but this isn't it.  Strictly speaking, you
never allocate or free anything as a float *.  You always
initially malloc (and eventually free) things as generic pointers
(void * on ANSI systems, char * on pre-ANSI systems), although
you frequently convert them to some other pointer type while
you're actually using them.

On an ANSI system, assuming you've #included <stdlib.h> or
otherwise ensured that prototypes for malloc() and free() are
in scope, you can do things like

        float *buf = malloc(...
        free(buf);

, without any casts, because whenever ANSI C sees a void *
(in this example, as the return value from malloc() or as
the expected argument to free()), it is happy to provide implicit
conversions, if necessary, between void * and the pointer type
you're using (float * in this example).

Before ANSI C introduced void pointers, however, casts *were*
required for strictly-correct and portable behavior:

        float *buf = (float *)malloc(...
        free((char *)buf);

Without these casts, you could either get warnings about
incompatible pointer types, or (on systems with physically
different pointer types) incorrect behavior, because you might
have passed a float * to free(), while it was expecting a char *.

Today, some people discourage these explicit casts, partly
because they're syntactically bulky and potentially confusing,
but more importantly because a cast on a call to malloc() might
mask warnings if it is not declared correctly (e.g. if it is
implicitly declared as int, because you forgot to #include
anything to declare it).  There's nothing formally wrong with
using the casts, though, particularly if you still care about
portability of your code to pre-ANSI systems.  (Any
misdeclaration of malloc() should still be caught by the "no
prototype in scope" or "implicit declaration" warnings which
many modern compilers provide.)  In any case, calling
free((char *)buf) cannot possibly break anything; it is
guaranteed to work (as long as you believe footnote 16 in the
ANSI Standard).  Jim's problem must be elsewhere.

                                        Steve Summit



Tue, 25 Feb 1997 23:32:39 GMT  
 free()'ing problems


: >> I determined that I'm having problems and finally found that the
: >> problem was in free()'ing previously allocated space...
:
Hi !
What about memory model used? If allocated structure size exceeds 64KB
(under DOS and Borland C at least) one have to compile in large or huge
memory model. Check this.

Janusz Opila.



Fri, 28 Feb 1997 19:55:21 GMT  
 free()'ing problems

: >I determined that I'm having problems and finally found that the
: >problem was in free()'ing previously allocated space. ...

How do you know this?  What are the symptoms? It would be useful if
you could post a (small) program which demonstrates the problem.

If the program crashes at the call to free() or free() returns an
error (some versions do/did), then it seems likely that you are
overwriting information that the heap management routines use to keep
track of the heap memory blocks.

I would recommend checking all accesses to buf between the call to
malloc() and to free().  An even better alternative is to get one of
the many debugging heap managers around that will tell you when your
heap is corrupt and other problems.

: > Normally, this
: >would be either 1) I mis-allocated something, or 2) I'm not freeing
: >the right things.  Neither of those two answers APPEARS to be correct.
: >ASSUMING that I haven't made either of those two errors, what else
: >could it be?

I think it is likely that the heap is corrupt.  Another possibility
is free'ing the same thing twice.

: >    if((buf=(float *)malloc((i2 - i1 +1)*(j2 - j1 +1)*sizeof(float)))
: >            ==NULL)

: >/*    free((char *)buf);  */

: Why free it as (char *) when allocating it as (float *)?  You maybe running
: into some kind of boundary alignment problem.  Try freeing it as a
: (float *).

This may be due to a pre standard compiler that expects the arg to
free to be a char *.  In any case it should not cause problems in a
standard compiler since any pointer can be cast to a char * (or void
*) with no loss of info.

: >Of course, I've included <malloc.h> and the other variables are
: >declared appropriately.
: >
: >
: >IF you can't answer the above question (or if I've made some error
: >that I told you I didn't make...), here is another:
: >
: >Except for possible memory allocation problems later in the program,
: >is there anything wrong with not free()ing up memory?  I assume all
: >goes back when the program finishes?  I'm just wanting to make sure
: >that my kludge doesn't have any hidden dangers.

Obviously there is nothing wrong with not free'ing memory except that
you won't be able to reallocate it later in the program.  (Generally
when the program terminates the OS recalims all memory allocated to it.)

Andrew.
--

--------------------------------
Just a SPOKE, not a SPOKESPERSON



Mon, 03 Mar 1997 07:42:53 GMT  
 
 [ 8 post ] 

 Relevant Pages 

1. Q:Frequent malloc'ing and free'ing

2. how to prevent 'free'-ing memory twice

3. Quickie on free()'ing malloc()'d mem

4. Structure member pointing to itself and free()'ing

5. free()'ing structs containing pointers to memory?

6. free()'ing structs .. continued

7. Free'ing memory

8. free-ing memory problem

9. DAO code samples - found some but having problems with Release'ing objects

10. read()'ing from a child's piped stdout

11. Q!!'scanf'ing strings with char**s

12. trouble with realloc'ing array of char *'s

 

 
Powered by phpBB® Forum Software