Malloc and free: memory being freed was not allocated - c

The following is from the Libaiff library. I get the following error completely randomly (i.e. sometimes my program works flawlessly and sometimes it gets stuck with this error and it always breaks at the same point within this function).
(1949,0x7fff7b82d310) malloc: * error for object 0xd00000000b400: pointer being freed was not allocated
* set a breakpoint in malloc_error_break to debug
My question is, if r->buffer2 has already been freed, then is it possible for the control to get past the statement if (r->buffer2) and into the block to try and execute free(r->buffer2)? In other words, if r->buffer2 has been freed, shouldn't the if (r->buffer2) prevent the freeing from trying to happen again?
static void AIFF_ReadClose(AIFF_Ref r)
{
if (r->buffer)
free(r->buffer);
if (r->buffer2)
free(r->buffer2); // THIS IS WHERE THE BREAK OCCURS EVERYTIME
Unprepare(r);
fclose(r->fd);
free(r);
return;
}
EDIT:
The following is the definition for AIFF_Ref:
struct s_AIFF_Ref {
FILE* fd;
int flags;
int stat; /* status */
int segmentSize;
int bitsPerSample;
int nMarkers;
int nChannels;
double samplingRate;
uint64_t nSamples;
int markerPos;
uint64_t len;
uint64_t soundLen;
uint64_t pos;
uint64_t sampleBytes;
uint64_t commonOffSet;
uint64_t soundOffSet;
uint64_t markerOffSet;
IFFType format;
IFFType audioFormat;
void* decoder;
void* pdata;
void* buffer;
size_t buflen;
void* buffer2;
size_t buflen2;
int tics;
};
typedef struct s_AIFF_Ref* AIFF_Ref;
Can anyone suggest why this strange behavior might be happening and how I might solve it?
Thanks.

From the documentation,
The free function deallocates a memory block (memblock) that was
previously allocated by a call to calloc, malloc, or realloc.( Assume first free case )
If memblock is NULL, the pointer is ignored and free immediately returns. (You never came here because, you never set your pointer to NULL)
Attempting to free an invalid pointer (a pointer to a memory block
that was not allocated by calloc, malloc, or realloc) may affect
subsequent allocation requests and cause errors. ( Assume second free case )
if (r->buffer2)
{
free(r->buffer2);
r->buffer2 = NULL ; // Always set the pointer to NULL,
// if you doubt that you may gonna 'free' the memory again,
// somewhere else.
}
if (r->buffer2)
{
free(r->buffer2);
r->buffer2 = NULL ;
}
This is because, when you free the memory, the free assures you that the memory will be free'd but it doesn't assures you that it will delete or NULL'ify the value written in the pointer variable. So, if( r->buffer2 ) holds TRUE for your case and hence, the flow enters the if block.

When you received the error message, one possibility was that it had been freed before, another possibility was that the value of the pointer had been changed to point to another memory.
To avoid this, you must pay attention not to change the pointer before you free it and after having freed memory, you should set the point to NULL.

According to the documentation you liked to, you're already provided with open and close functions, namely
AIFF_Ref AIFF_OpenFile(const char* name, int flags) ;
and
int AIFF_CloseFile(AIFF_Ref r) ;
This call should deallocate memory. Have you tried that?

The short answer to your question is no. Calling free(r->buffer2) does not prevent if (r->buffer2) from evaluating to true and subsequently calling free again. The reason is that free(r->buffer2) does not modify the value of r->buffer2. Think of it this way: if you hired a demolition company to go destroy a building, and you handed them a card with the address of the building you wanted destroyed, would the address written on the card suddenly disappear after they destroyed the building? No. A pointer is no different. It's just an address, stored in a variable that we call a "pointer" because it identifies a memory address. The piece of memory it points to is not the same thing as the pointer itself.
As to what is causing the duplicate call to free(), you haven't provided enough information to ascertain that, so one can only speculate.

Please find your question to response and some additional information which might be useful.
if r->buffer2 has been freed, shouldn't the if (r->buffer2) prevent
the freeing from trying to happen again?
There is no way to know the information that whether memory has already been freed or not. As someone has pointed out that checking pointer with 'null' does some sanity check and normally we do in that way. But this would work only when is your logic somebody set the pointer with 'null' after freeing the memory, otherwise the 'null' check would not work and your current code would execute the 'free' as the pointer is not assigned to 'null' while freeing the memory.
By looking the address, it looked to me that the 'buffer2' has some garbage value and you should be getting different address value whenever you might be running your program. This might occur in the scenario where 'AIFF_Ref' object might not have been initialized properly and still it holds some garbage value. One way to do it is to set
memset((void*)r, 0, sizeof(struct s_AIFF_Ref));
This would intialize all with default values. This may avoid the chances of any garbage value assigned to yout 'buffer2' variables.
You have mentioned that these are logic of some library hence I would recommend you to use some dynamic tool to understand the error quickly and and at the point where problem is happening.From your description it is also possible that your program has some sort of memory corruption. I think my previous post might be useful for this problem as well.
If your program is windows specific, you should see the following link:
https://stackoverflow.com/a/22074401/2724703
If your program is Gnu/Linux specific, you should see the following link:
https://stackoverflow.com/a/22085874/2724703

Related

Freeing dynamically allocated int that needs to be returned but cannot be freed in main in c

As my long title says: I am trying to return a pointer in c that has been dynamically allocated, I know, I have to free it, but I do not know how to myself, my search has showed that it can only be freed in main, but I cannot leave it up to the user to free the int.
My code looks like this right now,
int *toInt(BigInt *p)
{
int *integer = NULL;
integer = calloc(1, sizeof(int));
// do some stuff here to make integer become an int from a passed
// struct array of integers
return integer;
}
I've tried just making a temp variable and seeing the integer to that then freeing integer and returning the temp, but that hasn't worked. There must be a way to do this without freeing in main?
Program design-wise, you should always let the "module" (translation unit) that did the allocation be responsible for freeing the memory. Expecting some other module or the caller to free() memory is indeed bad design.
Unfortunately C does not have constructors/destructors (nor "RAII"), so this has to be handled with a separate function call. Conceptually you should design the program like this:
#include "my_type.h"
int main()
{
my_type* mt = my_type_alloc();
...
my_type_free(mt);
}
As for your specific case, there is no need for dynamic allocation. Simply leave allocation to the caller instead, and use a dedicated error type for reporting errors:
err_t toInt (const BigInt* p, int* integer)
{
if(bad_things())
return ERROR;
*integer = p->stuff();
return OK;
}
Where err_t is some custom error-handling type (likely enum).
Your particular code gains nothing useful from dynamic allocation, as #unwind already observed. You can save yourself considerable trouble by just avoiding it.
In a more general sense, you should imagine that with each block of allocated memory is associated an implicit obligation to free. There is no physical or electronic representation of that obligation, but you can imagine it as a virtual chit associated at any given time with at most one copy of the pointer to the space during the lifetime of the allocation. You can transfer the obligation between copies of the pointer value at will. If the pointer value with the obligation is ever lost through going out of scope or being modified then you have a leak, at least in principle; if you free the space via a copy of the pointer that does not at that time hold the obligation to free, then you have a (possibly virtual) double free.
I know I have to free it, but I do not know how to myself
A function that allocates memory and returns a copy of the pointer to it without making any other copies, such as your example, should be assumed to associate the obligation to free with the returned pointer value. It cannot free the allocated space itself, because that space must remain allocated after the function returns (else the returned pointer is worse than useless). If the obligation to free were not transferred to the returned pointer then a (virtual) memory leak would occur when the function's local variables go out of scope at its end, leaving no extant copy of the pointer having obligation to free.
I cannot leave it up to the user to free the int.
If you mean you cannot leave it up to the caller, then you are mistaken. Of course you can leave it up to the caller. If in fact the function allocates space and returns a pointer to it as you describe, then it must transfer the obligation to free to the caller along with the returned copy of the pointer to the allocated space. That's exactly what the calloc() function does in the first place. Other functions do similar, such as POSIX's strdup().
Because there is no physical or electronic representation of obligation to free, it is essential that your functions document any such obligations placed on the caller.
Just stop treating it as a pointer, there's no need for a single int.
Return it directly, and there will be no memory management issues since it's automatically allocated:
int toInt(const BigInt *p)
{
int x;
x = do some stuff;
return x;
}
The caller can just do
const int my_x = toInt(myBigInt);
and my_x will be automatically cleaned away when it does out of scope.

do we always need to check if the pointer not a null after malloc/realloc?

I am now studying C and in some code examples I saw that after we allocate some memory to a pointer, we have to check the pointer to be not a NULL. For example:
CVector *vector = malloc(sizeof(struct CVectorImplementation));
assert(vector != NULL);
another example:
vector->elements = realloc(vector->elements, vector->elemsz * vector->vec_capacity);
assert(vector->elements != NULL);
However, I think since the pointer is already been allocated, then it has the address of the allocated memory as its value, thus is it always necessary? why?
If you've reassigned the original pointer in response to realloc, it's too late to do anything useful in response to a failure. When realloc fails, it returns NULL, but it does not free the original pointer. So even if you have some reasonable response to an allocation failure (not common), you've already leaked the memory you were trying to realloc.
The answer to your main question is mostly "it's a bad idea to allow NULL pointer dereferences to occur because it's a source of vulnerabilities"; usually the vulnerabilities crop up in kernel code (where NULL is just as valid an address as anywhere else), but even when it's not exploitable, it means the program segfaults instead of reporting an error in a useful way.
It's a great idea to check the pointer returned from malloc/realloc.
If there's an error, you will get a null value returned. Use this check to your advantage because if you make reference to the same pointer later in your program and your program suddenly crashes, then chances are the pointer is set to null.
If you do have a valid pointer from a malloc/realloc call, then make sure you use it inside the free() function before deciding to modify the pointer value and before the program terminates, otherwise, you may run into memory leaks.
If you need to change the pointer value to write to a different section of the memory you allocated, then use another pointer.
Here's code in C that shows what I mean:
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
int main(){
char *block=calloc(1,10000);
if (block==NULL){
printf("Can't allocate memory\n");
return -1;
}
memset(block,48,20); //set 1st 20 bytes of memory to number zero (ascii code 48)
char *insideoftheblock=block+10; // I set a pointer to go to index #10 in the memory
*insideoftheblock='x';
*insideoftheblock++;
*insideoftheblock='y';
printf("Memory = '%s'",block);
free(block);
}
P.S.
I updated my code to include a check to see if memory has been actually allocated.
The realloc function attempts to allocate new memory. If this allocation fails then the realloc function returns NULL. Your code must deal with this situation.
If you want to abort your program in this case then the assert as you currently have it is suitable. If you want to recover, then you will need to store the realloc result in a separate variable while you assess the situation, e.g.:
void *new = realloc(vector->elements, vector->elemsz * vector->vec_capacity);
if ( !new )
// take some action.... the old vector->elements is still valid
else
vector->elements = new;
A failed allocation typical results in 1 of 2 actions:
1) Exit the program with a diagnostic. This is far better than not checking and letting the code continue to who--knows--what.
2) In select circumstances, code can cope with the failure. Maybe freeing other resources and trying again, return a failure code and leave the problem to the calling routine or writing a "suicide note" and re-starting the system. IAC, the action is very specific to the situation.
Robust code checks the result. Beginner code does not.

free(struct variable) doesn't clear previous stored values associated with that variable when I malloc again?

I created a struct like the following:
typedef struct header{
int hc;
char src[18];
char dst=[18];
char reason[15];
char d[3];
char m[3];
char y[4];
struct measurements{
char h_ip[17];
int h_ttl;
int h_id;
float h_rtt;
}HOPS[100];
}HEADER;
INSIDE MAIN:
HEADER *head;
for(...){
head=(HEADER*) malloc(sizeof(HEADER));
.....
free(head);
}
Will the above malloc automatically allocate memory for the inner struct as well? Also, I'm facing a weird problem here. After I free the header, I'm still able to print the values of head->HOPS[i].h_ip. Should I explicitly free the inner struct as well so that even the values get cleared?
Yes, it allocates memory for the inner structure. And you need not free the inner structure separately.
If you have a pointer defined inside your structure, in that case you have to allocate separately for that pointer member of the structure and free that separately.
Consider freeing memory as a black box. All what you know is that after freeing you shouldn't refer to freed memory.
You may find that that memory block still exists and still contains some old values. That's ok: it just was marked as freed and probably it will be used again soon by allocator.
For example when you call malloc again and realized that just allocated block contains values from the old structure. It happens and that's alright. Just use this block as usually.
So, after the problem with the wrong declaration of head was resolved:
free returns a previously allocated memory block to the heap. It does not clear anything (for performance reasons). However, you are not supposed to access that block anymore afterwards. Doing so results in undefined behaviour and might let your computer fly out of the window.
Worst that can happen is ... nothing ... Yes, you might even not notice anything strang happens. However, that does not mean your program run correctly, it just does not show any symptoms.
To catch illegal accesses, you might set the pointer to NULL once you freed the object it points to. Some operating systems catch accesses to addresses near the null pointer address, but there is no guarantee. It is a good practice anyway and does no harm.
For your other question: malloc allocates a block of memory large enough to store that many bytes you passed as argument. If it cannot, it will return a null pointer. You should always check if malloc & friends returned a valid pointer (i.e. not a null pointer).
int *p = malloc(sizeof(int));
if ( p == NULL ) {
error: out of memory
}
...
Notice the omission of the cast of the result of malloc. In C you should not cast void * as returned by malloc & friends (but also elsewhere). As much as you did not for free(head). Both take the same type: void *, btw. (so why cast one and not the other?). Note that in C any object pointer can freely be assigned to/from void * without cast. Warning functions are no objects in the C standard!
Finally: sizeof(HEADER) returns the size of the struct. Of course that include all fields. A nested struct is a field. A pointer to another struct is a field. For the latter, however note: the pointer itself is a field, but not what it points to! If that was another struct, you have to malloc that seperately **and also free seperately (remember what I wrote above).
But as you do not have pointer inside your struct, that is not your problem here. (keep it in mind, if you continue programming, you will eventually need that!)

malloc preventing garbage from being printed?

Program was programmed in C and compiled with GCC.
I was trying to help a friend who was trying to use trying to (shallow) copy a value that was passed into a function. His the value was a struct that held primitives and pointers (no arrays or buffers). Unsure of how malloc works, he used it similar to how the following was done:
void some_function(int rand_params, SOME_STRUCT_TYPEDEF *ptr){
SOME_STRUCT_TYPEDEF *cpy;
cpy = malloc(sizeof(SOME_STRUCT_TYPEDEF));// this line makes a difference?!?!?
cpy = ptr;// overwrites cpy anyway, right?
//prints a value in the struct documented to be a char*,
//sorry couldn't find the documentation right now
}
I told him that the malloc shouldn't affect the program, so told him to comment it out. To my surprise, the malloc caused a different output (with some intended strings) from the implementation with the malloc commented out (prints our garbage values). The pointer that's passed into the this function is from some other library function which I don't have documentation for at the moment. The best I can assume it that the pointer was for a value that was actually a buffer (that was on the stack). But I still don't see how the malloc can cause such a difference. Could someone explain how that malloc may cause a difference?
I would say that the evident lack of understanding of pointers is responsible for ptr actually pointing to memory that has not been correctly allocated (if at all), and you are experiencing undefined behaviour. The issue is elsewhere in the program, prior to the call to some_function.
As an aside, the correct way to allocate and copy the data is this:
SOME_STRUCT_TYPEDEF *cpy = malloc(sizeof(SOME_STRUCT_TYPEDEF));
if (cpy) {
*cpy = *ptr;
// Don't forget to clean up later
free(cpy);
}
However, unless the structure is giant, it's a bit silly to do it on the heap when you can do it on the stack like this:
SOME_STRUCT_TYPEDEF cpy = *ptr;
I can't see why there difference in the print.
can you show the print code?
anyway the malloc causes memory leak. you're not supposed to allocate memory for 'cpy' because pointer assignment is not shallow-copy, you simply make 'cpy' point to same memory 'ptr' point by storing the address of the start of that memory in 'cpy' (cpy is mostly a 32/64 bit value that store address, in case of malloc, it will store the address of the memory section you allocated)

Returning a pointer to an automatic variable

Say you have the following function:
char *getp()
{
char s[] = "hello";
return s;
}
Since the function is returning a pointer to a local variable in the function to be used outside, will it cause a memory leak?
P.S. I am still learning C so my question may be a bit naive...
[Update]
So, if say you want to return a new char[] array (ie maybe for a substring function), what do you return exactly? Should it be pointer to an external variable ? ie a char[] that is not local to the function?
It won't cause a memory leak. It'll cause a dangling reference. The local variable is allocated on the stack and will be freed as soon as it goes out of scope. As a result, when the function ends, the pointer you are returning no longer points to a memory you own. This is not a memory leak (memory leak is when you allocate some memory and don't free it).
[Update]:
To be able to return an array allocated in a function, you should allocate it outside stack (e.g. in the heap) like:
char *test() {
char* arr = malloc(100);
arr[0] = 'M';
return arr;
}
Now, if you don't free the memory in the calling function after you finished using it, you'll have a memory leak.
No, it wont leak, since its destroyed after getp() ends;
It will result in undefined behaviour, because now you have a pointer to a memory area that no longer holds what you think it does, and that can be reused by anyone.
A memory leak would happen if you stored that array on the heap, without executing a call to free().
char* getp(){
char* p = malloc(N);
//do stuff to p
return p;
}
int main(){
char* p = getp();
//free(p) No leak if this line is uncommented
return 0;
}
Here, p is not destroyed because its not in the stack, but in the heap. However, once the program ends, allocated memory has not been released, causing a memory leak ( even though its done once the process dies).
[UPDATE]
If you want to return a new c-string from a function, you have two options.
Store it in the heap (as the example
above or like this real example that returns a duplicated string);
Pass a buffer parameter
for example:
//doesnt exactly answer your update question, but probably a better idea.
size_t foo (const char* str, size_t strleng, char* newstr);
Here, you'd have to allocate memory somewhere for newstr (could be stack OR heap) before calling foo function. In this particular case, it would return the amount of characters in newstr.
It's not a memory leak because the memory is being release properly.
But it is a bug. You have a pointer to unallocated memory. It is called a dangling reference and is a common source of errors in C. The results are undefined. You wont see any problems until run-time when you try to use that pointer.
Auto variables are destroyed at the end of the function call; you can't return a pointer to them. What you're doing could be described as "returning a pointer to the block of memory that used to hold s, but now is unused (but might still have something in it, at least for now) and that will rapidly be filled with something else entirely."
It will not cause memory leak, but it will cause undefined behavior. This case is particularly dangerous because the pointer will point somewhere in the program's stack, and if you use it, you will be accessing random data. Such pointer, when written through, can also be used to compromise program security and make it execute arbitrary code.
No-one else has yet mentioned another way that you can make this construct valid: tell the compiler that you want the array "s" to have "static storage duration" (this means it lives for the life of the program, like a global variable). You do this with the keyword "static":
char *getp()
{
static char s[] = "hello";
return s;
}
Now, the downside of this is that there is now only one instance of s, shared between every invocation of the getp() function. With the function as you've written it, that won't matter. In more complicated cases, it might not do what you want.
PS: The usual kind of local variables have what's called "automatic storage duration", which means that a new instance of the variable is brought into existence when the function is called, and disappears when the function returns. There's a corresponding keyword "auto", but it's implied anyway if you don't use "static", so you almost never see it in real world code.
I've deleted my earlier answer after putting the code in a debugger and watching the disassembly and the memory window.
The code in the question is invalid and returns a reference to stack memory, which will be overwritten.
This slightly different version, however, returns a reference to fixed memory, and works fine:
char *getp()
{
char* s = "hello";
return s;
}
s is a stack variable - it's automatically de-referenced at the end of the function. However, your pointer won't be valid and will refer to an area of memory that could be overwritten at any point.

Resources