我想知道malloc和free是怎么工作的。
int main() {
unsigned char *p = (unsigned char*)malloc(4*sizeof(unsigned char));
memset(p,0,4);
strcpy((char*)p,"abcdabcd"); // **deliberately storing 8bytes**
cout << p;
free(p); // Obvious Crash, but I need how it works and why crash.
cout << p;
return 0;
}
如果答案是在记忆层面上的深度，如果可能的话，我会非常感激。
当前回答
你的程序崩溃是因为它使用了不属于你的内存。它可能被其他人使用，也可能没有——如果你幸运的话，你崩溃了，如果没有，问题可能会隐藏很长一段时间，然后回来咬你一口。
就malloc/free实现而言——整本书都致力于这个主题。基本上，分配器会从操作系统中获得更大的内存块，并为你管理它们。分配器必须解决的一些问题是:
How to get new memory How to store it - ( list or other structure, multiple lists for memory chunks of different size, and so on ) What to do if the user requests more memory than currently available ( request more memory from OS, join some of the existing blocks, how to join them exactly, ... ) What to do when the user frees memory Debug allocators may give you bigger chunk that you requested and fill it some byte pattern, when you free the memory the allocator can check if wrote outside of the block ( which is probably happening in your case) ...
其他回答
这很难说，因为不同的编译器/运行时之间的实际行为是不同的。即使是调试/发布版本也有不同的行为。VS2005的调试版本将在分配之间插入标记来检测内存损坏，因此它将在free()中断言，而不是崩溃。
这取决于内存分配器的实现和操作系统。
Under windows for example a process can ask for a page or more of RAM. The OS then assigns those pages to the process. This is not, however, memory allocated to your application. The CRT memory allocator will mark the memory as a contiguous "available" block. The CRT memory allocator will then run through the list of free blocks and find the smallest possible block that it can use. It will then take as much of that block as it needs and add it to an "allocated" list. Attached to the head of the actual memory allocation will be a header. This header will contain various bit of information (it could, for example, contain the next and previous allocated blocks to form a linked list. It will most probably contain the size of the allocation).
Free将删除头文件并将其添加回空闲内存列表。如果它与周围的自由块形成一个更大的块，这些块将被加在一起，形成一个更大的块。如果整个页面现在是空闲的，分配器很可能会将该页返回给操作系统。
这不是一个简单的问题。操作系统分配器部分完全不受您的控制。我建议您阅读Doug Lea的Malloc (DLMalloc)之类的东西，以了解一个相当快的分配器是如何工作的。
编辑:你的崩溃将由这样一个事实引起，即写大于分配，你已经覆盖了下一个内存头。这样，当它释放时，它会非常困惑，不知道它到底释放了什么，以及如何合并到下面的块中。这可能并不总是会直接导致免费的崩溃。这可能会导致以后的崩溃。一般避免内存覆盖!
理论上，malloc为这个应用程序从操作系统获取内存。然而，由于您可能只需要4个字节，而操作系统需要在页面上工作(通常是4k)， malloc所做的要比这多一点。它取一个页面，并把它自己的信息放在那里，这样它就可以跟踪你从该页中分配和释放了什么。
例如，当分配4个字节时，malloc会提供一个指向4个字节的指针。您可能没有意识到的是，在4个字节之前的8-12个字节的内存被malloc用来构成您已分配的所有内存的链。当你调用free时，它会取你的指针，备份到它的数据所在的位置，并对其进行操作。
当你释放内存时，malloc将内存块从链上取下…并且可能会也可能不会将这些内存返回给操作系统。如果它这样做，那么访问内存可能会失败，因为操作系统将拿走你访问该位置的权限。如果malloc保留内存(因为它在该页中分配了其他内容，或者用于某些优化)，则访问将正常工作。这仍然是错误的，但可能会起作用。
免责声明:我所描述的是malloc的一种常见实现，但绝不是唯一可能的实现。
好的，关于malloc的一些答案已经发布了。
更有趣的部分是free是如何工作的(在这个方向上，malloc也可以更好地理解)。
In many malloc/free implementations, free does normally not return the memory to the operating system (or at least only in rare cases). The reason is that you will get gaps in your heap and thus it can happen, that you just finish off your 2 or 4 GB of virtual memory with gaps. This should be avoided, since as soon as the virtual memory is finished, you will be in really big trouble. The other reason is, that the OS can only handle memory chunks that are of a specific size and alignment. To be specific: Normally the OS can only handle blocks that the virtual memory manager can handle (most often multiples of 512 bytes e.g. 4KB).
所以返回40字节到操作系统将不能工作。那么，免费有什么作用呢?
Free会把内存块放在它自己的空闲块列表中。通常情况下，它还尝试将地址空间中的相邻块融合在一起。空闲块列表只是一个循环的内存块列表，在开始的时候有一些管理数据。这也是为什么使用标准malloc/free管理非常小的内存元素效率不高的原因。每个内存块都需要额外的数据，越小的内存块就会产生越多的碎片。
当需要新的内存块时，malloc首先查看的还是空闲列表。在它从操作系统调用新内存之前，它会被扫描。当发现一个块比所需的内存大时，它被分为两部分。一个返回给调用者，另一个返回到空闲列表中。
对于这个标准行为有许多不同的优化(例如对于小块内存)。但是，由于malloc和free必须是通用的，所以当不可用替代方案时，标准行为总是一个退路。在处理空闲列表方面也有优化——例如将块存储在按大小排序的列表中。但是所有的优化也有其局限性。
为什么你的代码崩溃:
原因是，通过将9个字符(不要忘记后面的空字节)写入大小为4个字符的区域，您可能会覆盖存储在您的数据块“后面”的另一个内存块的管理数据(因为该数据通常存储在内存块的“前面”)。当free试图将您的块放入空闲列表时，它会接触到这个管理数据，因此会碰到一个被覆盖的指针。这会使系统崩溃。
This is a rather graceful behaviour. I have also seen situations where a runaway pointer somewhere has overwritten data in the memory-free-list and the system did not immediately crash but some subroutines later. Even in a system of medium complexity such problems can be really, really hard to debug! In the one case I was involved, it took us (a larger group of developers) several days to find the reason of the crash -- since it was in a totally different location than the one indicated by the memory dump. It is like a time-bomb. You know, your next "free" or "malloc" will crash, but you don't know why!
这些是一些最糟糕的C/ c++问题，也是指针问题如此严重的原因之一。
同样重要的是要意识到，简单地使用brk和sbrk移动程序断点指针实际上并不分配内存，它只是设置了地址空间。例如，在Linux上，当访问该地址范围时，内存将由实际的物理页“备份”，这将导致页错误，并最终导致内核调用页分配器以获得备份页。
