I have a question to ask, which occurred when reading the concept of static variables. If I create an allocated block of memory in a function, using malloc, and then the function returns to main, without having used free() on the allocated memory, will that memory block be susceptible to changes in the course of the program, or not? I mean, after I leave the function is it possible that the memory block can be overwritten by another process, while I wanted to use it and/or edit it in my way, or is it "locked" from something like that, until I free it? Is it possible for the block to be considered as free of data before I free it?
Once you malloced a certain num ber of bytes, it's going to be alive throughout your program's lifetime unless you explicitly free it.
It doesn't matter in which function you did the malloc, the memory is going to be alive for you to use anywhere in your program provided you have a valid pointer to the malloced memory.
The C Standard specifies a storage duration called allocated (in C99 6.2.4 Storage duration of objects.) The lifetime of allocated storage is from allocation (with malloc, calloc, realloc) until deallocated (with free or realloc). So, yes, returning from a function does not invalidate allocated storage (unlike automatic storage like local variables). You can expect it to be still allocated. And you can read and write it as long as you have a valid pointer to such storage.
When memory is allocated with malloc, it stays allocated to your program as long as your program is running and as long as you do not free this memory block. So this memory block cannot be modified or overwritten by another process.
Generally, the malloced memory block cannot be overwritten by another process because the two processes reside in two different virtual address spaces, unless you share the memory block with another process in some way like this.
OK, so I think you're asking what happens in a situation like this...
#include <stdlib.h>
void myfunc( void )
{
static void* p = malloc(BLOCK_SIZE);
// perhaps the rest of this function uses the pointer to the allocated mem...
}
int main( int argc, char** argv )
{
myfunc();
// the rest of the program goes here...
}
... and asking if "the rest of the program" code could write into the memory block allocated by myfunc().
The heap would still have the memory allocated, as it doesn't know that only the code in myfunc() holds a pointer to the memory block. But it won't 'lock' it either (i.e. protect it from being written to -- there is no such concept in the C language itself.)
Due to the heap still regarding the memory block as already allocated no code that used a subsequent malloc() would get a pointer to a block that is within the one you already allocated. And no code outside of myfunc() would know the the value of the pointer p. Thus the only way any later code could end up writing to the block is 'accidentally' by somehow gaining a pointer to a location that happened to be within the memory in your block (probably due to some sort of code bug), and writing to it.
Related
So I was reading through some code for a class and I am a little confused about how variable's are deallocated in C.
The code given is
#include<stdio.h>
main () {
int n=0;
char *p = "hello world";
while (*p!= 0) { // *p != '\0';
putc(*p, stdout);
p++;
}
printf("\np = %d", *p);
printf("\np = %d\n", p);
}
So i get that you don't need to free any memory for the char* since no mallocs are happening but i don't get why this code wouldn't leak any memory... If you are incrementing a pointer for a string and thus moving pointer to the next block of memory (1byte) then aren't you losing the initial reference and all reference points that you increment over? How would would this memory be reclaimed without a reference point, unless one is saved by the compiler before this type of operation occurs. I would appreciate some insight on how this is being reclaimed!
The task of deallocating memory is imposed on the owner of that memory. Just because you have a pointer to some memory region does not mean that you own that memory and, therefore, does not mean that you are responsible for deallocating it.
String literal "hello world" is an object with static storage duration. It is stored in static memory. Static memory is always owned by the runtime environment. The runtime environment is aware of data stored in static memory. The runtime environment knows when that data has to be deallocated (which is easy, since static memory is basically "never" deallocated - it exists as long as your program runs).
So, again, you with your pointer p do not really own any memory in static region. You just happen to refer to that memory with your p . It is not your business to worry about deallocation of that memory. It will be properly deallocated when the time comes (i.e. when the program ends) and it will be done properly without any help from you and your pointer p. You can change your p as much as you want, you can make it point to a completely different memory location, or you can discard it without any reservations. Speaking informally, nobody cares about your p.
The only memory you can possibly own in a C program is memory you personally allocated with malloc (or other dynamic memory allocation functions). So, you have to remember to eventually call free for the memory that you allocated yourself (and you have to make sure you know the original value returned by malloc to pass to that free). All other kinds of memory (like static or automatic) are never owned by you, meaning that freeing it is not your business and preserving the original pointer values is completely unnecessary.
You aren't leaking any memory because you are not dynamically allocating any memory. Memory leaks come from not freeing dynamically allocated memory. Locally allocated memory (like char *p) or statically allocated memory (like the string "hello world" that p initially points at) cannot contribute to leaks.
You are not dynamically allocating any new memory, hence you do not need to free it.
The string literal "hello world" is an object which is part of the program itself. When the "hello world" expression is evaluated, the program essentially obtains a pointer to a piece of itself. That memory cannot be deallocated while the program is running; that would be equivalent to making a "hole" in the program. The memory has the same lifetime as the program itself.
In the C language, the programmer is not required to manage memory which has the same lifetime as the program: this is externally managed (or mismanaged, as the case may be) by the environment which starts the program, and deals with the aftermath when the program terminates.
Of course, the memory still has to be managed; it's just that the responsibility does not lie with the C program. (At least, not in an environment which provides a hosted implementation of the C language. The rules for some embedded system might be otherwise!)
In a program that is embedded, the string literal (along with the rest of the program) could actually live in ROM. So there might really be nothing to clean up. The pointer is an address which refers to some permanent location on a chip (or several chips).
In short: because the program itself is short. You could be doing any malloc you want in there, and no leaks would actually happen, since all the memory is handed back to the OS as soon as the process ends. A leak would not be an issue in your example. Anyway,
in your case, a leak is not happening, because the variable p is pointing to a literal string, which is located in the data segment of the memory (i.e. it is a constant, written in the executable). This kind of memory cannot be de-allocated, because its space is fixed.
Actually, it is false that this is not a problem, because a very big executable, with lots of big constants in it, could have a remarkable memory footprint, but anyway this is not called a leak, because memory usage may be big, but it does not increase over time, which is the main point of a memory leak (hence the name leak).
When you declare your variables locally, the compiler knows how much space is required for each variable and when you run your program, each local variable (and also each function call) is put on stack. Just after return statement (or } bracket if void function) each local variable is popped from stack, so you don't have to free it.
When you call new operator (or malloc in pure C), the compiler doesn't know the size of the data, so the memory is allocated runtime on heap.
Why I'm explaining this is fact that whenever you call new or malloc (or calloc), it's your responsibility to free memory you don't want to use anymore.
In addition to the other answers, incrementing a pointer in C doesn't create or lose "references", nor does it cause any copying or other altering of the memory that the pointer points to. The pointer in this case is just a number that happens to point to a statically allocated area of memory.
Incrementing the pointer doesn't alter the bytes that the pointer used to point to. The "H", is still there. But the program now thinks that the string starts with "e". (It knows where the end of the string is because by convention strings in C end with a null.
There are no checks that the pointer points to what you think it should, or any valid area at all. The program itself could lose track of an area of memory (for instance if you set p=0), or increment p beyond the end of the string, but the compiler doesn't keep track of this (or prevent it), and it doesn't de-allocate the memory used for the string.
If you change the pointer to point to the "wrong" location in memory, fun (bad) things will happen - such as page faults, stack overflows and core dumps.
I am working on learning c. I understand that malloc() allocates a block of bytes that cannot be changed or corrupted without user request, however I find myself using it very often. To be exact, I am using malloc every time that I want to create either a struct or any of its contents that I want to reference in the future. I also do understand to free() the allocated memory when its complete.
Is my use of malloc correct?
Dynamic memory allocation (malloc and family) are there for two reasons:
Your data needs to persist beyond the scope that allocated it (e.g. multithreading)
Whatever you are allocating is too large for your stack
You should really be avoiding to allocate dynamic memory for any other reason. Automatic (stack) variables are far less prone to errors and are automatically deallocated for you at the end of the scope.
Having "corrupted memory" like you call it can only really arise from bad programming and can happen on both the stack and the heap and you should not rely on dynamic memory to provide safety from buffer overflows or other mistakes that lead to memory corruption.
There is a reason why many functions in the C standard library get a pointer to a buffer as an argument to put results in: it allows you to allocate those buffers on your stack. e.g:
ssize_t read(int fd, void *buf, size_t count);
Also as mentioned by another answer: Your stack memory is already in the CPU cache and is thus far faster accessible.
Please also consider the other types of allocation:
int foo;
outside of a block will allocate a global variable, which is alive during the whole lifetime of your process, and visible for other modules of the program.
static int foo;
outside of a block is the same but visible in the actual module only.
int foo;
inside a block is alive only while the code in the block runs, then it's destroyed.
static int foo;
inside a block is visible in the block only, but it preserves its value for the entire lifetime of the process.
I'm doing a lot of embedded C coding, and using malloc() is absolutely prohibited. And it's entirely possible. You typically need malloc() if you don't know the size of your problem at compile time. But even in some cases like that, you can replace dynamic memory allocation with other techinques like recursion, line-based processing etc, etc.
It depends on what you mean by
cannot be changed or corrupted without user request
If you are referring to code - then it's usually called client, not user. And it's still unclear what do you mean by that. But that's not the point.
The point is that malloc() is one of the functions used for dynamic memory allocation. It means that you can pass an address returned by this function somewhere else and data stored there will be there until it's manually deallocated. Unlike static memory allocation which is automatically freed when it's out of the scope.
So, you probably shouldn't be using malloc() if memory allocated by it is freed in the same scope, just because it's meaningless and because static allocation is faster because it's easier for CPU to cache and it's initialized at program startup, not at runtime as heap allocated memory.
I have allocated memory to some data type and assigned some value. Now using free is the data in the memory deleted or not? What is use of using free if the data assigned is not deleted? Can anyone help me out? Ex:
int *arr;
arr=(int*)malloc(sizeof(int)*1000);
assert(arr!=NULL);
/*Some operation*/
arr[123]=354;
//some operations
printf("%d",*(arr+123));
//calling some funcs
free(arr);
printf("\n%d",*(arr+123));
The point of free is to make the memory you allocated available for following calls to malloc. It does not guarantee that the buffer passed to it is wiped in any way.
In fact, what you're doing is provoking undefined behavior; accessing a buffer that has been free'd might give the value that was previously stored in it, or any other value, or it might crash your program, or do anything else.
You cannot "delete" things from memory.
What free() does is it reclaims the memory, so that it can be recycled by a future call to malloc().
You cannot legally dereference a pointer that you got from malloc() (or any other dynamic allocation call) after calling free() on it. Doing so invokes undefined behavior.
By using malloc you set aside a specified number of bytes to be used for what ever you want. Returned is an address to the area. The memory area is also flagged in a special table as occupied meaning it can't be reserved by another process or another malloc.
When you free the allocated memory the area is flagged as free, but the data is not erased. If you want to erase the data you'll have to do a memset or manually loop and set data to 0 or some other value before you free it.
As mentioned by others the operation on free memory is undefined.
A short introduction to how memory can be arranged. Look i.e. at heap:
http://www.geeksforgeeks.org/archives/14268 or Fig 1. at bottom of this comment: Strange global variable behaviour, once variable name is changed issue disappears
I have written some more about the malloc process itself here:
Can some explain the performance behavior of the following memory allocating C program? where also virtual vs. physical memory, pages etc are some of the points.
I am struggling to wrap my head around malloc in c - specifically when it needs to be free()'d. I am getting weird errors in gcc such as:
... free(): invalid next size (fast): ...
when I try to free a char pointer. For example, when reading from an input file, it will crash on certain lines when doing the following:
FILE *f = fopen(file,"r");
char x[256];
while(1) {
if(fgets(x,sizeof x,f)==NULL) break;
char *tmp = some_function_return_char_pointer(x); //OR malloc(nbytes);
// do some stuff
free(tmp); // this is where I get the error, but only sometimes
}
I checked for obvious things, such as x being NULL, but it's not; it just crashes on random lines.
But my REAL question is - when do I need to use free()? Or, probably more correctly, when should I NOT use free? What if malloc is in a function, and I return the var that used malloc()? What about in a for or while loop? Does malloc-ing for an array of struct have the same rules as for a string/char pointer?
I gather from the errors I'm getting in gcc on program crash that I'm just not understanding malloc and free. I've spent my quality time with Google and I'm still hitting brick walls. Are there any good resources you've found? Everything I see says that whenever I use malloc I need to use free. But then I try that and my program crashes. So maybe it's different based on a variable's scope? Does C free the memory at the end of a loop when a variable is declared inside of it? At the end of a function?
So:
for(i=0;i<100;i++) char *x=malloc(n); // no need to use free(x)?
but:
char *x;
for(i=0;i<100;i++) {
x=malloc(n);
free(x); //must do this, since scope of x greater than loop?
}
Is that right?
Hopefully I'm making sense...
malloc() is C's dynamic allocator. You have to understand the difference between automatic (scoped) and dynamic (manual) variables.
Automatic variables live for the duration of their scope. They're the ones you declare without any decoration: int x;
Most variables in a C program should be automatic, since they are local to some piece of code (e.g. a function, or a loop), and they communicate via function calls and return values.
The only time you need dynamic allocation is when you have some data that needs to outlive any given scope. Such data must be allocated dynamically, and eventually freed when it is no longer necessary.
The prime usage example for this is your typical linked list. The list nodes cannot possibly be local to any scope if you are going to have generic "insert/erase/find" list manipulation functions. Thus, each node must be allocated dynamically, and the list manipulation functions must ensure that they free those nodes that are no longer part of the list.
In summary, variable allocation is fundamentally and primarily a question of scope. If possible keep everything automatic and you don't have to do anything. If necessary, use dynamic allocation and take care to deallocate manually whenever appropriate.
(Edit: As #Oli says, you may also want to use dynamic allocation in a strictly local context at times, because most platforms limit the size of automatic variables to a much smaller limit than the size of dynamic memory. Think "huge array". Exceeding the available space for automatic variables usually has a colourful name such as "pile overrun" or something similar.)
In general, every call to malloc must have one corresponding call to free.* This has nothing to do with scope (i.e. nothing to do with functions or loops).
* Exceptions to this rule include using functions like strdup, but the principle is the same.
Broadly speaking, every pointer that is ever returned by malloc() must eventually be passed to free(). The scope of the variable that you store the pointer in does not affect this, because even after the variable is no longer in scope, the memory that the pointer points to will still be allocated until you call free() on it.
Well, the scope of the malloc'd memory lays between calls to malloc and free or otherwise until process is stopped (that is when OS cleans up for the process). If you never call free you get a memory leak. That could happen when address that you can pass to free goes out of scope before you actually used it - that is like loosing your keys for the car, car is still there but you can't really drive it. The error you are getting is most likely either because function returns a pointer to some memory that was not allocated using malloc or it returns a null pointer which you pass to free, which you cannot do.
You should free memory when you will no longer be accessing it. You should not free memory if you will be accessing it. This will give you a lot of pain.
If you don't want memory leak, you have to free the memory from malloc.
It can be very tricky. For example, if the // do some stuff has a continue, the free will be skipped and lead to memory leak. It is tricky, so we have shared_ptr in C++; and rumor has it salary of C programmer is higher than C++ programmer.
Sometimes we don't care memory leak. If the memory holds something that is needed during the whole lifetime of execution, you can choose not to free it. Example: a string for environment variable.
PS: Valgrind is a tool to help detect memory bugs. Especially useful for memory leak.
malloc(n) allocates n bytes of memory from a memory location named heap and then returns a void* type of pointer to it. The memory is allocated at runtime. Once you have allocated a memory dynamically, scope does not matter as long as you keep a pointer to it with you(or the address of it specifically). For example:
int* allocate_an_integer_array(int n)
{
int* p = (int*) (malloc(sizeof(int)*n));
return p;
}
This functions simply allocates memory from heap equal to n integers and returns a pointer to the first location. The pointer can be used in the calling function as you want to. The SCOPE does not matter as long as the pointer is with you..
free(p) returns the memory to heap.
The only thing you need to remember is to free it as if you don't free it and lose the value of its address, there will bw a memory leak. It is so because according to OS, you are still using the memory as you have not freed it and a memory leak will happen..
Also after freeing just set the value of the pointer to null so that u don't use it again as the same memory may be allocated again at any other time for a different purpose....
So, all you need to do is to be careful...
Hope it helps!
Please excuse my C newbiness.
Consider the following C procedure:
int doSomething() {
char *numbers="123456";
...
}
Before this procedure exits should I be releasing the 'numbers' pointer?
No, you didn't malloc it. Why should you release it?
Often, the string is placed in a read only section of the executable.
In C language you don't and can't "release" pointers. Pointers are ordinary scalar variables. There's nothing you can do with them in terms of "releasing" or anything like that.
What one can be "releasing" is the memory a pointer is pointing to. But in C you only have to release memory that was explicitly allocated by malloc/calloc/realloc. Such memory is released by calling free.
Note again, that in your program you might have several (a hundred) pointers pointing to the same block of allocated memory. Eventually, you'll have to release that memory block. But regardless of how many pointers you have pointing to that block, you have to release that memory block exactly once. It is your responsibility to make sure that you release it. And it is your responsibility to make sure you released it exactly once. I'm telling you this just to illustrate the fact that what you release is the memory block, not the pointers.
In your example, your pointer points to a memory block that was never allocated by any of the aforementioned functions. This immediately means that you don't need to release anything.
No, there is no need to do so, and doing so is incorrect (thanks dmckee). The character string will be in the data segment of the binary, so it can't be freed. The memory was not dynamically allocated.
"numbers" will be on the stack, so it will go away when the function returns.
you don't actually need to call delete or free , these operators are only used to clean up memory that have been allocated my runtime memory allocator like malloc, calloc , GlobalAlloC, HeapAlloc and so forth. When you define a pointer like in the example you are actually allocating space for array of character in the the execuatable file. so bigger the string length bigger will be the executable size thus increasing your working set.
No; there's nothing to release. The string literal "123456" is an array of char (const char in C++) with static extent. The memory for it is allocated at program startup and held until the program exits. All you've done is assign the address of the string literal to numbers; you haven't actually allocated any memory.
NO, since it was not allocated by malloc/ calloc / realloc.
It will be automatically "freed" because it is an automatic variable.
No, it points to pre-allocated memory in process data segment. Only free(3) what you have malloc(2)-ed (modulo some library functions like getaddrinfo(3)/freeaddrinfo(3).)