※ 引述《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 --core=core_a.out.1234 : 想问说~ 难道一定要user自己在电脑想办法开core dump的能力而无法透过自己 : application 本身"暂时" 开启吗? 找不太到文章 man setrlimit : 以上虽然可以用undefined behavior来解释 : 可是如果想知道更深入的概念 该怎麽做 ls /usr/share/man/man2 把下面看得到的东西全部 man 一遍，读完，然後 trace glibc 跟 Linux kernel。 如果这苦工跟你志向不合，你可以找做过这类事情的人问问。 OS 跟 MMU 的互动从 OS 跟计算机结构课本上可以学个大概，细节可以问专家。 : 谢谢 -- Ling-hua Tseng Senior Engineer Compiler Group, RD/Software Division Andes Technology Corporation --

※ 发信站: 批踢踢实业坊(ptt.cc), 来自: 122.116.164.123 ※ 文章网址: https://webptt.com/cn.aspx?n=bbs/C_and_CPP/M.1530688947.A.B7C.html 我前面有讲啊，推测是 operator<< 内部的实作可能用了 new / delete。 光是你 (2) 这一行就呼叫了整整五次： cout << "read after free: " << ptr << ":" << *ptr << endl; (2) 你那几次 cout 输出了一堆东西，这个输出动作就在你 main thread 里。 也许你觉得那只不过是输出东西到萤幕上，但内部动作其实颇复杂的。 你每呼叫一次 operator<< 都有破坏的可能性，只是什麽时候破坏就看运气问题。 ※ 编辑: tinlans (122.116.164.123), 07/04/2018 20:19:07