CODEWITHSUNDEEP
cmemory-managementrealloc
Arulprakasan
Arulprakasan

Reputation: 61

realloc crashes when the input address is points to invalid address

realloc may return either the same input address or a different address. If it returns a different address then it shall internally de-allocate/free the input memory and moving that content into an another location and returns that new address.

Please consider the following case.

new_ptr = realloc (2000, 10000)  // Lets assume the input address is 2000 

// Lets assume the new_ptr address is 3000

So, internally realloc shall free the memory where pointer points to 2000 and move those data into a new location 3000 and return the 3000 address.

Now the address 2000 is points to invalid. Hence it is not assigned to NULL by realloc API.

Now, passing that invalid address to realloc function. In real time there may be changes that realloc may get the invalid input address. 

new_ptr = realloc(2000, 10000)

This 2000 address is invalid since it is already freed by previous realloc. Now the program crashes.

Can I resolve this issue by doing the following way. 

      if (new_ptr != old_ptr ) {
        old_ptr = NULL;                      
      }

Since the old_ptr is invalid. I shall assign it to NULL. Please confirm me the correction.

Upvotes: 0

Views: 373

Answers (2)

Rohit
Rohit

Reputation: 152

Realloc will free the old memory block if it is successful. NOTE: if it can append in the same memory block it will append there itself. If it is not able to append it will create a new memory block and free the old one.

if you have any loop logic or you are using pointer that point to old memory block inside function after realloc is done.Than yes crash will come. if old pointer is just to do realloc than no need.Since local pointer you have created and its scope will be limited to that function.Every time you call the function it will be new pointer varaible.

Upvotes: 0

user2371524
user2371524

Reputation:

Think about your first sentence:

realloc may return either the same input address or a different address.

This implies you can just use the return value as your new pointer, you don't have to know whether it's different from your previous one or not. If it is different, realloc() already handled freeing the previous block for you.

But there's one exception: realloc() may return 0 / NULL if the allocation fails. Only in this case, the old pointer is still valid. Therefore, the common idiom to use realloc() correctly looks like this:

T *x = malloc(x_size);
// check x for NULL

// [...]

T *tmp = realloc(x, new_size);
if (!tmp)
{
    free(x);
    // handle error, in many cases just exit(1) or similar
}
x = tmp; // use the new pointer, don't care whether it's the same

Note that using x (from my example above) after a successful call to realloc() is undefined, according to the C standard, x is invalid after the call. This doesn't tell you anything about the actual value of x. It just tells you "Don't use it, otherwise your program might do anything".

This self-quote might help you to understand what undefined behavior means:

Undefined behavior in C

C is a very low-level language and one consequence of that is the following:

Nothing will ever stop you from doing something completely wrong.

Many languages, especially those for some managed environment like Java or C# actually stop you when you do things that are not allowed, say, access an array element that does not exist. C doesn't. As long as your program is syntactically correct, the compiler won't complain. If you do something forbidden in your program, C just calls the behavior of your program undefined. This formally allows anything to happen when running the program. Often, the result will be a crash or just output of "garbage" values, as seen above. But if you're really unlucky, your program will seem to work just fine until it gets some slightly different input, and by that time, you will have a really hard time to spot where exactly your program is undefined. Therefore avoid undefined behavior by all means!.

On a side note, undefined behavior can also cause security holes. This has happened a lot in practice.

Upvotes: 5

Related Questions