How the memory management unit(MMU) detects the double free of a pointer?
I know that its a good practice to make the pointer NULL just after freeing it, but suppose programmer does not do it. Is there any MMU mechanism to detect it?
+12
A:
The MMU has nothing to do with it. If you free a pointer allocated with malloc twice you will probably corrupt the C runtime heap. The heap (not the MMU) can in principle protect itself against such things, but most don't. Please note that this has nothing to do with the operating system - neither malloc() nor free() are system calls.
anon
2010-02-13 11:45:03
It could in principle protect itself, but with most applications still being 32-bit and allocating gigabytes of memory in their lifetime, you have to reuse at some point. Unless you decide to do some very sophisticated and impressive tricks in the compiler. http://portal.acm.org/citation.cfm?id=1543135.1542505 and compiler homepage: http://staff.aist.go.jp/y.oiwa/FailSafeC/index-en.html
Pascal Cuoq
2010-02-13 12:36:12
+5
A:
How the memory management unit(MMU) detects the double free of a pointer?
The MMU just does virtual address space -> physical memory mapping, it doesn't know anything about how the heap is organized/how the allocation works/..., that is operating system/allocator work.
How does OS detects the double free then? Whats the mechanism??
It walks the list/bitmap/... of allocated blocks, sees that there's no allocated block with the address you passed to it, so it detects that it's a double free.
However if that block has already been re-allocated, it finds it and correctly free it => but now the code that used the re-allocated block will go nuts, since the memory it has correctly acquired and that it didn't release has become unallocated.
If the allocator protects the unallocated memory marking it as no-read and no-write/removing it from the committed pages of the virtual address space the program will die as soon as that memory is accessed again (but the code that apparently caused the crash will be actually innocent, since it didn't do anything wrong).
Otherwise, the application may still work for some time, until that memory block will be given to some other piece of code that requested some memory. At that point, two pieces of the same application will try to work on the same block of memory, with all the mess that can originate from this.
(Thanks to Pascal Cuoq for pointing out my error.)
Matteo Italia
2010-02-13 11:47:45
It's not "skipping" the check. There is no check. It **has** to walk the list of allocated blocks, because until the last one the runtime doesn't know if you are not freeing a live block. The reason strange things happen in practice is that the previously freed block may have been re-used, in which case it is freed again, under the feet of the code using it.
Pascal Cuoq
2010-02-13 14:19:07
+3
A:
No, there is no MMU mechanism to detect it. It is common that calling free on an already free'd address causes the program to crash as the implentation of free does something unexpected and causes a segmentation fault.
Running valgrind is a good way of checking for memory management problems, such as double freeing a pointer.
Hans W
2010-02-13 12:00:02
A:
Got your point, MMU has nothing to do with it...
How does OS detects the double free then? Whats the mechanism??
Srikanth
2010-02-13 12:59:54
I updated my answer (http://stackoverflow.com/questions/2257342/how-mmu-detects-double-free-of-a-pointer/2257355#2257355); check it out.
Matteo Italia
2010-02-13 13:30:58
It doesn't, normally. It just tries to free it again, fails, and crashes.
Hans W
2010-02-13 13:32:38
@Srikanth Please do not ask supplementary questions by posting an answer - append them to your original question.
anon
2010-02-13 14:11:12
+1
A:
Setting it to NULL isn't actually a good practice, it hides bugs. Particularly double free()s. Check the OS memory map, something like 0xfeeefeee or 0xdeadbeef is usually good.
You can diagnose double free()s with a debug allocator. Most any decent CRT has one.
Hans Passant
2010-02-13 13:51:08