Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Mike Lewis on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Question on free()

Status
Not open for further replies.

BTon15

Programmer
Nov 21, 2001
29
0
0
GB
I've declared a local variable as char* in my function (non-static) and then I've done malloc() to reserve some memory for it.

I then use the variable and return from my function.

If I don't free() the memory, will it be deallocated anyway since it is only in scope within the function?

I seem to be getting a core dump when calling free() and wondered if it is because I'm calling strtok on my local variable.

Thanks in advance for any help.
 
It must be free'ed only after use, and not necessary inside of function, malloc'ated the memory.
 
Whenever you malloc some memory, you must free it ... but only (as mingis says) after you have finished using/referencing it.



--------------------------------------------------
Free Database Connection Pooling Software
 
> will it be deallocated anyway since it is only in scope within the function?
The only way you can be sure that the memory is released is to do it yourself with free. Many systems will release allocated memory when the program terminates, but that's not a requirement.

> I seem to be getting a core dump when calling free()
The memory is getting corrupted somehow. This could be because you didn't allocate enough, such as with malloc(strlen(s)) (it should almost always be malloc(strlen(s) + 1)), or if you wrote outside of the boundaries through a logical error.

> wondered if it is because I'm calling strtok on my local variable
No, even if you call strtok on a string in dynamic memory, you still have to call free on the address that was returned by malloc. Just because strtok appears to break up the string doesn't mean that the structure of the memory has changed.
 
> will it be deallocated anyway since it is only in scope within the function?
No.
How would malloc ever return a pointer if this were true?

Each malloc needs exactly one free, but its quite usual for memory to be allocated in one place and freed in another.

> if it is because I'm calling strtok on my local variable.
So long as your strtok doesn't access outside the memory you allocated, no it won't affect it.
strtok only changes the bytes within the allocated block (as does say strcpy).

> I seem to be getting a core dump when calling free()
This usually means you've trashed the memory pool somehow. Unfortunately for you, it is seldom anything to do with the most recent call to malloc.

Code:
char *p = malloc( 10 );
strcpy( p, "hello world" ); // oops!
// more code
char *q = malloc( 20 );  // may or may not segfault
strcpy( q, "foo bar" );  // OK (in itself)
free( q );               // may or may not segfault
Basically, at any time after the "oops", your program is on thin ice. A crash can happen at any time between immediately and never.

--
 
scope of local variables: C is influenced by machine design. Local variables are (usually) stored in stack space, same as return addresses. That means it's practically impossible to keep the local variable while returning to the original parent function (note: if you want "local" variables to keep their value between calls to a function, then the compiler has to treat them like global variables and put them in the data segment). The very act of returning (finding the return address on the stack, reloading it into the processor's instruction pointer/cs registers, and clearing up function parameters) gets rid of any stack space dedicated to the called function's local variables.

But malloc allocates space in the memory at large, outside the stack area. Therefore a simple return from a function doesn't automatically deallocate anything malloced. Returning from your function deallocates the tiny bit of memory (4 bytes) occupied by the address where your string will be held, the address being in stack space. The actual string is somewhere else, and isn't deallocated unless you use free.

Of course a compiler is free to work however it wants provided it works; the picture above is for a typical C compiler on a typical PC.
 
Thanks for all your help guys.

It turned out that I was doing malloc(strlen(str1)) followed by a strcpy() to copy str1 into my new area of memory.

Of course I should have been doing malloc(strlen(str1)+1).

It was all working ok until I tried to free the memory, but I guess that was just by chance.
 
Another thing to note ... If useing C++ at all, use new and delete are recomended in placr of malloc and free -- but don't mix them as the behavior of calling delete on malloc'd memory or free on new memory is not defined by the C99 standards.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top