1

I was reading a textbook which describes a common mistake when dealing with dynanmic memory allocation, below is the buggy code:

int *heapref(int n, int m)
{
   int i;
   int *x, *y;
 
   x = (int *)malloc(n * sizeof(int));  //line 6
   .
   . // Other calls to malloc and free
   .
   free(x);                             //line 10

   y = (int *)Malloc(m * sizeof(int));  //line 12
   for (i = 0; i < m; i++)
       y[i] = x[i]++; /* Oops! x[i] is a word in a free block */

   return y;
}

And the author says:

Depending on the pattern of malloc and free calls that occur between lines 6 and 10, when the program references x[i] in line 14, the array x might be part of some other allocated heap block and may have been overwritten

I'm a little bit confused here, the only thing that can cause issue to me is the line 12 which allocates a new memory block after free(x) , if I comment out line 12, then the program will still function correctly by luck, isn't it? How does malloc and free calls that occur between lines 6 and 10 affect sth that actually happen after itself?

  • Once you've freed memory, you cannot access it anymore. Reading freed memory results in undefined behaviour. If you comment out line 12, the memory pointed by `x` _may_ still contain the previous values. And even if you don't comment out line 12, the memory pointed by `x` _may_ still contain the previous values. It's _undefined behaviour_ (google that term). – Jabberwocky Sep 29 '20 at 08:30
  • 1
    Also please read [Do I cast the result of malloc?](https://stackoverflow.com/questions/605845/do-i-cast-the-result-of-malloc). – Some programmer dude Sep 29 '20 at 08:33
  • As for your question: After you call `free(x)`, where does `x` point? Do you own the memory where it points? – Some programmer dude Sep 29 '20 at 08:34
  • Reading freed memory usually results in following scenarions: 1. the memory still contains the same values as before the free. 2. the memory contains indetermined values, which will probably will confuse the program logic sooner or later. 3. the program could crash instantly. For more information google "read freed memory" – Jabberwocky Sep 29 '20 at 08:40
  • 2
    Using `x` after `free(x)` is simply undefined behavior. [What is undefined behavior and how does it work?](https://software.codidact.com/questions/277486). – Lundin Sep 29 '20 at 08:42
  • @Jabberwocky I know it is undefined behaviourr, I just don't understand why it is related to the code between line 6 and 10? –  Sep 29 '20 at 08:45
  • 2
    The author refers to _one possible_ scenario: once you've freed `x`, the `y = malloc(...` in the following will reuse the same memory that `x` was pointing to, therefore `x` and `y` might point to the same memory or to overlapping memory. Or maybe just disregard what the author says and mind that it's just undefined behaviour. – Jabberwocky Sep 29 '20 at 08:48
  • @Jabberwocky yes that's what I thought originally, but since the author says "Depending on the pattern of malloc and free calls that occur between lines 6 and 10", I thought I might miss something –  Sep 29 '20 at 09:02
  • @Jabberwocky could you also have a look at this question please? https://stackoverflow.com/questions/64116210/assuming-uninitialized-heap-memory-is-initialized-to-zero-when-using-mmap –  Sep 29 '20 at 09:03
  • I'd just disregard what the author says and mind that reading from memory that is not your's it's just plain old undefined behaviour. – Jabberwocky Sep 29 '20 at 09:25
  • Read also this: https://stackoverflow.com/questions/1584392/can-looking-at-freed-memory-cause-an-access-violation – Jabberwocky Sep 29 '20 at 09:27

0 Answers0