dangling pointer, reason for value change after free()?

Question

In the following code segment, after free(x), why does y become 0?

As per my understanding, the memory in the heap that was being pointed to by x, and is still being pointed to by y, hasn't been allocated to someone else, so how can it change to 0?

And moreover, I don't think it is free(x) that changed it to 0.

Any comments?

#include <stdio.h>

int main(int argc, char *argv[])
{
    int *y = NULL;
    int *x = NULL;

    x = malloc(4);
    *x = 5;

    y = x;
    printf("[%d]\n", *y); //prints 5

    free(x);

    printf("[%d]\n", *y); //why doesn't print 5?, prints 0 instead

    return 0;
}

Solar flares. This is almost always because of solar flares. — Tim Post, Apr 01 '10 at 07:54

score 12 · Answer 1 · answered Apr 01 '10 at 07:22

12

This is undefined behavior, explanations are just speculation.

I can speculate that maybe you are running a debug version of the C library, and that the debug version of free() does zero the pointed area.

answered Apr 01 '10 at 07:22

Didier Trosset

36,376
13
83
122

+1, absolutely. The question is actually meaningless because there is no defined answer. – Cruachan Apr 01 '10 at 07:32
Except that usually debug heap managers will explicitly fill freed memory with something *other than* zero. – Michael Burr Apr 01 '10 at 07:39
2

@Cruachan - Not quite meaningless, the answer quite definitive, its undefined. Undefined is undefined. – Tim Post Apr 01 '10 at 07:54

score 4 · Answer 2 · answered Apr 01 '10 at 07:21

4

What is done in free depends on the implementation. It is not prohibited to zero out the memory after it's freed.

And what you're doing is undefined behavior.

answered Apr 01 '10 at 07:21

kennytm

510,854
105
1,084
1,005

score 2 · Answer 3 · answered Apr 01 '10 at 07:27

2

Doesn't y points to the same address as x, after line

y = x;

If you free x, you will also free the memory pointed by y.

If you are wondering why it prints '0', that undefined behavior, but I've seen it as a practice before, that some programmers, sets the freed area to '0'.

Download this video called "Binky the pointer fun video" (it's not a joke, actually is very educative), and you'll get pointers better.

answered Apr 01 '10 at 07:27

Andrei Ciobanu

12,500
24
85
118

1

I understand what are dangling pointers!, I was just trying to understand y=0 behavior. – Aman Jain Apr 01 '10 at 07:33

score 2 · Answer 4 · edited Aug 03 '17 at 09:55

The call to free() will put the memory block that had been allocated by malloc() back onto data structures that the C runtime maintains for the heap (in this case something that might be called the 'free-list).

Manipulating the heap data structures might incidentally change what was being pointed to by y (since the program doesn't own the memory anymore, it has no reason to believe the memory shouldn't change).

In a non-debug build of the program, the runtime typically won't do anything specifically to invalidate freed memory, but as I mentioned, it may still make changes as a result of its own bookkeeping (though since the memory doesn't belong to the caller anymore, the runtime is allowed to do whatever it likes).

In a debug build, the runtime will probably explicitly overwrite the memory to a value that is likely to be invalid if the program does use it in the hopes that it will cause a problem that identifies the problem more readily. Usually the value used to overwrite the freed memory block isn't zero, since zero will often not expose a bug (i.e. NULL pointer checks will cause the code to 'handle' the invalid memory access). For example, MSVC's debug heap manager will overwrite freed memory with the value 0xDD (see When and why will an OS initialise memory to 0xCD, 0xDD, etc. on malloc/free/new/delete? for more details).

dangling pointer, reason for value change after free()?

4 Answers4

Linked