問題(Question)：
在大型系統遇到了一些問題
有一個副程式A裡面做的事情是free動態記憶體
它的code就是傳入記憶體再把它free掉
所以很多function都有用到他
但有某個function寫錯了呼叫了A free了不該free的記憶體
有方法可以知道是哪個function呼叫了A嗎?
因為印出的log只有顯示死在A
很多function都沒加log, 因此完全看不到東西
但關鍵應該是呼叫的那個function傳的記憶體位置
老實說只想到在每個function呼叫A前都加個printf看看兇手是誰
但這樣有點像土法煉鋼
想知道有沒有更聰明的方法知道是哪個function呼叫的
感覺上應該是有方法的
謝謝大家

我的方法是寫 Macro 把 __FILE__ 和 __LINE__ 傳進來再把這兩項加入此 function 的 log 印出來就行了

用olly吧

一樓的方法其實就是自動化你所想到的方法如果拿不到 stack trace 的話這不失為一個好方法差不多, 不過函數本身一般參數即可, __FILE__ 用 char* 接__LINE__ 用 int 接函數的參數名自己另外訂, 不能直接用 __FILE__ __LINE__

extern 一般會集中在 header 吧，只需要改一次如果同一個 function 的 extern 散落各處，趁這機會修理否則現在不出事，將來若改到 prototype 一樣會出事

我習慣會用#直接把macro 轉字串如果有支援c99的話 也可以用__func___

如果是 glibc 的話直接 backtrace() 印出來就好了Windows API 似乎也有 stack inspection 但我是沒用過

所以我前面就提了拿不到 stack trace 再說, 不然找那個最快

如果在副程式中把ESP存起來呢?這樣就知道最後是誰CALL的不是ESP,把call retn的stack返回地址存起來

這其實就是 stack trace 實際上是怎麼追出來的方法配合除錯資訊中哪裡到哪裡是哪個函式就能建構出 trace 了但一般程式是不容易抓到這個地方的, 除非對環境很了解(ie. 能知道要怎麼去找到這個返回地址)所以這種東西多半是 runtime 才會/才能提供

VC 的話有這個macro

dump file 然後用工具看call stack