布奇
ㄇㄉ好久沒被 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:編譯+跑到爆炸的地方大概要半小時,我的時間就這樣沒ㄌ
載入新的回覆