求助:为何还能访问delete之后的空间

playmud

是不是讨论一下为什么free和delete(暂且不管delete的原理)是否应该控制一下访问权限？
对控制读是否有必要？
我想实现不让你访问应该可以实现，但是如果这么做了带来的负面影响是什么？

思一克

控制不了吧。

道理和这类似：

malloc 1024个字节，写入1024个0，然后设法使第128个字节不可读，也不可写。做不到。

原帖由 playmud 于 2006-5-25 11:19 发表
是不是讨论一下为什么free和delete(暂且不管delete的原理)是否应该控制一下访问权限？
对控制读是否有必要？
我想实现不让你访问应该可以实现，但是如果这么做了带来的负面影响是什么？

playmud

原帖由 思一克 于 2006-5-25 11:43 发表
控制不了吧。

道理和这类似：

malloc 1024个字节，写入1024个0，然后设法使第128个字节不可读，也不可写。做不到。

malloc的过程是一个线性地址和物理地址对应，并且设定各种标志的过程吧，能不能从这个地方入手？
我想既然可以针对
char * str;
memcpy(str,"sdss");
这种不分配就进行memcpy的行为给出错误，那么同样也可以对free掉的指针只想作出不可读的标志。

playmud

偶先去翻翻相关内存管理的文档，再来讨论。

Alligator27

我觉得关键是搞清楚内存分配使用中三方的责任与关系：用户程序，内存管理器(libc malloc)，kernel虚拟内存管理器（ＶＭＭ）．前两个都在用户空间．

用户程序使用malloc/free调用libc，粒度是一字节（实际要大一些，视系统对齐的要求而定）．

libc malloc使用brk/sbrk/mmap/munmap调用VMM分配内存空间，粒度是系统页面大小，比如最常见的４ＫＢ．

用户程序读写某地址是否成功，取决于该地址是否在VMM已分配空间之内．或者是否在进程的页表中．

举例说，用户程序申请８字节（malloc（８）），libc如果没有找到空闲的内存块，就会向VMM要４ＫＢ（实际的实现要大，sbrk(4096)). libc把４ＫＢ的头８字节给用户程序使用，其余的作为空闲块保留．这个时候，用户程序只应当读写libc给的头８字节，但既使它读写整个４ＫＢ的地址空间也不会crash．　
同样的原因，用户程序释放这８字节（free(p)）后，libc如果发现整个４ＫＢ的地址空间都空闲，它可以把这一页归还VMM（sbrk(－4096)). 用户程序再读写这８字节，或这４ＫＢ的任何地址空间，都会seg fault. 然而大多数情况下，libc不会把这一页归还VMM，原因可以是页的地址空间中还有内存块在使用中，或者libc想把它缓存以提高速度．就象大家说的，libc只是标示８字节内存块是空闲块，或者与前后的空闲块合并以减少碎片．用户程序再读写这８字节是不会crash，但后果是不确定的．

原帖由 playmud 于 2006-5-25 11:19 发表
是不是讨论一下为什么free和delete(暂且不管delete的原理)是否应该控制一下访问权限？
对控制读是否有必要？
我想实现不让你访问应该可以实现，但是如果这么做了带来的负面影响是什么？

访问权限是ＶＭＭ提供的，libc malloc可以调用mprotect/VirtualProect来控制，缺点是ＶＭＭ操作是系统页为单位，空间和性能消耗很大．作为内存调试是可以的，比如Electric Fence，以及我的AccuTrak http://accutrak.sourceforge.net

playmud

楼上说得是linux的内存堆管理的东西吧，很清楚，多谢。

Alligator27

原帖由 playmud 于 2006-5-25 23:46 发表
楼上说得是linux的内存堆管理的东西吧，很清楚，多谢。

各平台在这点上大同小异

_Erics

原帖由 Alligator27 于 2006-5-25 22:31 发表
我觉得关键是搞清楚内存分配使用中三方的责任与关系：用户程序，内存管理器(libc malloc)，kernel虚拟内存管理器（ＶＭＭ）

恩 终于了解了～～