ㄇㄉ好久沒被 segmentation fault 搞了

今天一大早就被PV寄了封我的code造成seg fault的信，然後就整天都在de這個 bug。

用了 gdb 發現爆在把 string 加到 set 的地方，但我百思不得其解為什麼 STL 會爆炸，細看發現 string 裡的指標居然是dangling pointer，頭更痛了；而且連 gdb 的 call stack 資訊也一團亂，過半的 call stack 都只剩亂碼，根本天要亡我。

好家在我靈機一動把某處的find改成rfind就解決了問題，速速把修正完的code上傳準時下班，可喜可賀。

...才怪。

越想越不對勁的我把筆電帶回家加班，這才發現我直接在公司的code裡埋了地雷

（續）

因為 gdb 被弄得一團混亂，我只好從問題發生前一步一步執行，看到底發生什麼事（註 1）。

trace 到爆炸前幾行，突然 gdb 的資訊唰地消失了一大半。幹，原來是 char[] 的緩衝區溢位了，把一大半的變數、包含 string 中的指標、甚至是 gdb 的 call stack 全都覆蓋掉了，難怪白天 gdb 執行到這裡會像剛打完仗一樣。

至於為什麼 find 改成 rfind 會有用，大概只是運氣好吧，未來看誰不小心踩到就又炸了

註 1：為什麼白天不這麼做ㄋ？因為我一開始懷疑錯嫌犯了，我以為是 rvalue 參考會有 dangling 的問題，結果花了很多時間確定這個猜測是錯的。另外是他爆在一個會呼叫很多次的函式裡，想到不知道要手動 trace 多久就覺得累（不過還好他大概在第十幾次就爆了）

註 2：編譯+跑到爆炸的地方大概要半小時，我的時間就這樣沒ㄌ