释放后是否可以强制Linux使虚拟内存无效

Question

On Windows, I have noticed that trying to dereference a pointer to recently freed memory results in a crash, trapped by Visual Studio stating that the memory is invalid. This is as expected. However, executing the same application and code path leading to dereferencing a pointer to recently freed memory does not immediately cause a crash in Linux. This suggests to me that the Linux kernel (or GNU C++ run-time) does not invalidate freed memory very quickly, even on debug builds. The application takes much longer to crash. Is this the case? If so, can I force the memory to be unmapped more quickly? If not then what's going on?

Answer 1

Have you tried http://valgrind.org/ ? It's purpose is to help track down problems such as the one you've described.

Answer 2

Most implementations of new / delete do not return memory immediately to the system, or at least don't return smaller blocks. I'm rather surprised that your code crashed under Windows simply by dereferencing a pointer to the memory; are you sure you didn't do more than that (eg use the value you read through the pointer).

How big was the block? Many implementations use different strategies depending on the size of the block, and will free very large blocks immediately. (IIRC, Linux will do a mmap immediately for very large blocks, and unmap it immediately when you free it. Of course, if you reallocate memory between the free and dereferencing the pointer, it's possible that the address is in the newly allocated space, and it won't crash.)

In the end: the granularity of mapping is the page, and you cannot expect the allocator to block up a complete page for each allocation, just so that it can invalidate the memory immediately on deallocation. (A page is probably at least 4K, and you don't want to loose 4K address space each time you allocate 16 bytes.) Short of tracking all memory accesses (like ValGrand or Purify), and running a lot slower, the only alternative is to use garbage collection, to ensure that the memory isn't reallocated as long as there is a pointer to it, and overwrite it completely on deallocation (ie in delete or free ) with values that are likely to cause problems if used ( 0xDEADBEEF , or something like that). And even then, you're not really guaranteed that you'll crash— 0xDEADBEEF could be a valid value for what you think you're reading. (But this does allow eg setting a flag in the constructor, resetting it in the destructor, and testing it in each function. For code that has to be actively defensive.)