我想知道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;
}
如果答案是在记忆层面上的深度，如果可能的话，我会非常感激。
当前回答
您的strcpy行尝试存储9个字节，而不是8个字节，因为有NUL结束符。它调用未定义的行为。
The call to free may or may not crash. The memory "after" the 4 bytes of your allocation might be used for something else by your C or C++ implementation. If it is used for something else, then scribbling all over it will cause that "something else" to go wrong, but if it isn't used for anything else, then you could happen to get away with it. "Getting away with it" might sound good, but is actually bad, since it means your code will appear to run OK, but on a future run you might not get away with it.
使用调试风格的内存分配器，您可能会发现在那里写了一个特殊的保护值，free会检查该值，如果没有找到它就会惊慌失措。
否则，您可能会发现接下来的5个字节包括属于某个尚未分配的其他内存块的链接节点的一部分。释放块很可能涉及将其添加到可用块的列表中，并且由于您在列表节点中乱写了代码，该操作可能会解除对具有无效值的指针的引用，从而导致崩溃。
这完全取决于内存分配器——不同的实现使用不同的机制。
其他回答
Malloc和free依赖于实现。典型的实现包括将可用内存划分为“空闲列表”——可用内存块的链表。许多实现人为地将它分为小对象和大对象。空闲块以内存块有多大以及下一个内存块在哪里等信息开始。
当你malloc时，一个块从空闲列表中拉出来。当你释放时，块被放回空闲列表。很有可能，当你重写指针的末尾时，你是在写空闲列表中一个块的头。当您释放内存时，free()尝试查看下一个块，并可能最终击中导致总线错误的指针。
malloc/free的一个实现如下所示:
通过sbrk() (Unix调用)从操作系统获取一块内存。 在该内存块周围创建一个页眉和页脚，并提供一些信息，如大小、权限以及下一个和上一个块的位置。 当传入对malloc的调用时，引用一个指向适当大小的块的列表。 然后返回这个块，页眉和页脚也相应地更新。
这与malloc和free没有特别的关系。你的程序在复制字符串后表现出未定义的行为——它可能在那一点或之后的任何一点崩溃。即使您从未使用malloc和free，并在堆栈上或静态地分配char数组，也会出现这种情况。
内存保护具有页面粒度，并且需要内核交互
你的示例代码本质上是在问为什么示例程序没有陷阱，答案是内存保护是一个内核特性，只应用于整个页面，而内存分配器是一个库特性，它管理。没有强制执行…任意大小的块，通常比页面小得多。
内存只能以页为单位从程序中删除，即使这样也不太可能被观察到。
如果需要，Calloc(3)和malloc(3)会与内核交互以获取内存。但是大多数free(3)的实现都不会将内存返回给内核1，它们只是将内存添加到一个空闲列表中，稍后calloc()和malloc()会参考这个列表，以便重用释放的块。
即使free()函数想要将内存返回给系统，它也需要至少一个连续的内存页才能让内核实际保护该区域，因此释放一个小块只会导致保护更改，如果它是页面中的最后一个小块。
So your block is there, sitting on the free list. You can almost always access it and nearby memory just as if it were still allocated. C compiles straight to machine code and without special debugging arrangements there are no sanity checks on loads and stores. Now, if you try and access a free block, the behavior is undefined by the standard in order to not make unreasonable demands on library implementators. If you try and access freed memory or meory outside an allocated block, there are various things that can go wrong:
Sometimes allocators maintain separate blocks of memory, sometimes they use a header they allocate just before or after (a "footer", I guess) your block, but they just might want to use memory within the block for the purpose of keeping the free list linked together. If so, your reading the block is OK, but its contents may change, and writing to the block would be likely to cause the allocator to misbehave or crash. Naturally, your block may be allocated in the future, and then it is likely to be overwritten by your code or a library routine, or with zeroes by calloc(). If the block is reallocated, it may also have its size changed, in which case yet more links or initialization will be written in various places. Obviously you may reference so far out of range that you cross a boundary of one of your program's kernel-known segments, and in this one case you will trap.
操作原理
So, working backwards from your example to the overall theory, malloc(3) gets memory from the kernel when it needs it, and typically in units of pages. These pages are divided or consolidated as the program requires. Malloc and free cooperate to maintain a directory. They coalesce adjacent free blocks when possible in order to be able to provide large blocks. The directory may or may not involve using the memory in freed blocks to form a linked list. (The alternative is a bit more shared-memory and paging-friendly, and it involves allocating memory specifically for the directory.) Malloc and free have little if any ability to enforce access to individual blocks even when special and optional debugging code is compiled into the program.
1. The fact that very few implementations of free() attempt to return memory to the system is not necessarily due to the implementors slacking off. Interacting with the kernel is much slower than simply executing library code, and the benefit would be small. Most programs have a steady-state or increasing memory footprint, so the time spent analyzing the heap looking for returnable memory would be completely wasted. Other reasons include the fact that internal fragmentation makes page-aligned blocks unlikely to exist, and it's likely that returning a block would fragment blocks to either side. Finally, the few programs that do return large amounts of memory are likely to bypass malloc() and simply allocate and free pages anyway.
您的strcpy行尝试存储9个字节，而不是8个字节，因为有NUL结束符。它调用未定义的行为。
The call to free may or may not crash. The memory "after" the 4 bytes of your allocation might be used for something else by your C or C++ implementation. If it is used for something else, then scribbling all over it will cause that "something else" to go wrong, but if it isn't used for anything else, then you could happen to get away with it. "Getting away with it" might sound good, but is actually bad, since it means your code will appear to run OK, but on a future run you might not get away with it.
使用调试风格的内存分配器，您可能会发现在那里写了一个特殊的保护值，free会检查该值，如果没有找到它就会惊慌失措。
否则，您可能会发现接下来的5个字节包括属于某个尚未分配的其他内存块的链接节点的一部分。释放块很可能涉及将其添加到可用块的列表中，并且由于您在列表节点中乱写了代码，该操作可能会解除对具有无效值的指针的引用，从而导致崩溃。
这完全取决于内存分配器——不同的实现使用不同的机制。
