我看的是 the c programming language 8.7 a storage allocator,
裡頭就提供了 malloc.c 的一種實作。
以這個實作來說, free 之後, 如果沒有再次呼叫 malloc/free,
被 free 的那塊應該是可以安全使用, 因為沒有人會改寫指向 free 的位址的
linked list 資料結構。
但我不確定其他的實作品有什麼其他的魔法, 會造成這種效果。
一點心得:
https://descent-incoming.blogspot.com/2015/06/c-mallocfree.html
※ 引述《lovejomi (JOMI)》之銘言：
: 最近被問說 為什麼use after free後 你使用那塊memory的話 "有可能"會crash 或是
: 不會
: 我答不出來(這邊不討論 delete後 值被改動 foo->ptr已經變成垃圾指標 造成的acces
: s 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要超過我d
: emand的)
: 然而我delete了 除了cstdlib裡面free做了一些事情外 , 他很可能也會跟OS講說我這塊
: memory已經沒有要使用了(這邊不確定是不是每次 這是不是造成下面行為差異的主因)
: 再來我連續的 對這塊記憶體做讀取 和 寫入
: 1. 如果只是讀取而已 有沒有可能 造成crash? (以我測試來說 從沒因為read 而cras
: h, 但如果真的有可能會 我想知道為什麼)
: 2. 寫入比較不理解, 我拿到的是user space address, 雖然我delete了 但我write的時
: 候並沒有寫在其他超出user space的記憶體或是read-only的區段
: 為什麼 "有機會" 造成 SIGSEGV? 到底是誰 raise這signal?
: 3. 上面程式碼 (2) "有時候"會印出*ptr = 0,有時候是原來數值, 雖然我也只知道值不
: 可預期, 但我想問的是, 到底是誰把0 寫入進去? 是cstdlib嗎? 如果是的話 照理講要每
: 次都變0, 但顯然不是每次
: 以我測試, 如果我掛上valgrind ./a.out ==> 這行就不會變0 維持原來數值, 一旦直
: 接./a.out 就會是0
: 以上到底是誰介入了? 這件事我想說很可能是-O之類的差異 但我發現似乎不是 deb
: ug / release build都有這種現象.
: 然而有時候這一行就直接SIGSEGV了如同2.所問的問題
: 4. 我有用signal handler 擷取這SIGSEVG 我天真的想要把這件事給吃下來
: 但我看文章說 signal handler return後會回到 原本執行到的code
: 以我測試來說 我會 無限迴圈的觸發SIGSEGV , 想問一下是不是不可能吃得下來 一
: 定要 abort或是把handler設定成default 讓系統自己handle
: 5. 補個問題我嘗試在ubuntu產生core dump
: 大概做了幾件事
: echo 'core_%e.%p' | sudo tee /proc/sys/kernel/core_pattern
: core_%e.%p
: ulimit -c unlimited
: gdb a.out