※ 引述《lovejomi (JOMI)》之铭言：
: 最近被问说 为什么use after free后 你使用那块memory的话 "有可能"会crash 或是
: 不会
: 我答不出来(这边不讨论 delete后 值被改动 foo->ptr已经变成垃圾指标 造成的
: access violation)
: 原因是 如果只是单纯access 不管是read write, 我都不觉得会crash.... 以下是
: 我的测试和认知
: https://ideone.com/HKYiIQ
: int* ptr = new int;
: *ptr = 123;
: cout << "before: " << ptr << ":" << *ptr << endl; (1)
: delete ptr;
: cout << "read after free: " << ptr << ":" << *ptr << endl; (2)
: *ptr = 456; // write after free
: cout << "read after free: "<< ptr << ":" << *ptr << endl; (3)
: 我的认知
: new会透过cstdlib malloc要一块 valid的user space address (他应该会跟OS要超过
: 我demand的)
new 不一定透过 C library 的 malloc() 去要内存，只是大多数实作是这样。
: 然而我delete了 除了cstdlib里面free做了一些事情外 , 他很可能也会跟OS讲说我这
: 块memory已经没有要使用了(这边不确定是不是每次 这是不是造成下面行为差异的主因)
malloc() 和 free() 通常为了减少 system call 的次数而进行一些最佳化。
要内存的时候会多要一点，释放内存的时候不会立即归还。
特别是早期 UNIX 是用 brk() 和 sbrk() 这种移动栅栏的方式去实作，
如果刚好 heap 尾巴有还没 free 的空间，也不可能把栅栏退回去。
现代实作还会搭配 mmap() 跟 munmap()，所以这类问题的影响也变小了。
: 再来我连续的 对这块内存做读取 和 写入
: 1. 如果只是读取而已 有没有可能 造成crash? (以我测试来说 从没因为read 而
: crash, 但如果真的有可能会 我想知道为什么)
当然有可能会，没 crash 是因为 free() 没把要来的空间归还的关系。
已经还回去的话就是非法内存存取，会直接吃到 SIGSEGV。
你可以呼叫 mmap() 去拿一块内存，用 munmap() 归还以后对那个位址 read 看看。
: 2. 写入比较不理解, 我拿到的是user space address, 虽然我delete了 但我write的时
: 候并没有写在其他超出user space的内存或是read-only的区段
: 为什么 "有机会" 造成 SIGSEGV? 到底是谁 raise这signal?
你好像误会了什么，不是 address 落在 user space 就随便你读。
process 依然要跟 OS 申请 user space 里的空间，没申请到的区域你不能摸。
虽说这个讲法并非通用于所有 OS，但是在有 SIGSEGV 这名词出现的 OS 几乎都是这样。
你用上面提到的 mmap() -> munmap() 实验玩一下就会知道。
会 raise 这种 signal 的当然是 OS。
至于 OS 为什么会知道要 raise 这个 signal，那是因为它和 MMU 之间有互动。
: 3. 上面程式码 (2) "有时候"会印出*ptr = 0,有时候是原来数值, 虽然我也只知道值不
: 可预期, 但我想问的是, 到底是谁把0 写入进去? 是cstdlib吗? 如果是的话 照理讲要
: 每次都变0, 但显然不是每次
: 以我测试, 如果我挂上valgrind ./a.out ==> 这行就不会变0 维持原来数值, 一旦
: 直接./a.out 就会是0
: 以上到底是谁介入了? 这件事我想说很可能是-O之类的差异 但我发现似乎不是
: debug / release build都有这种现象.
: 然而有时候这一行就直接SIGSEGV了如同2.所问的问题
照常理来推断，应该是 operator<< 的实作部分可能有 new / delete。
然后有什么东西刚好被配置在同样的地方，然后被写进了 0。
开 gdb 下 watch point 应该可以抓到精确位置。
valgrind 是用 LD_PRELOAD 的机制替换了内存配置相关的 functions，
所以内存配置行为会和正常执行时有所不同，这很正常。
: 4. 我有用signal handler 撷取这SIGSEVG 我天真的想要把这件事给吃下来
: 但我看文章说 signal handler return后会回到 原本执行到的code
: 以我测试来说 我会 无限循环的触发SIGSEGV , 想问一下是不是不可能吃得下来
: 一定要 abort或是把handler设定成default 让系统自己handle
你大概忘记一件很重要的事情。
从 signal handler 返回的话，原本被停下来的事情会被重做。
除非你能把原本非法的 address 变成合法，不然就是无限触发 SIGSEGV。
: 5. 补个问题我尝试在ubuntu产生core dump
: 大概做了几件事
: echo 'core_%e.%p' | sudo tee /proc/sys/kernel/core_pattern
: core_%e.%p
: ulimit -c unlimited
: gdb a.out