作者usanhuang (呱呱)
看板C_and_CPP
標題[問題] 關於副程式呼叫
時間Wed Nov 23 23:28:34 2016
問題(Question)：
在大型系統遇到了一些問題
有一個副程式A裡面做的事情是free動態記憶體
它的code就是傳入記憶體再把它free掉
所以很多function都有用到他
但有某個function寫錯了呼叫了A free了不該free的記憶體
有方法可以知道是哪個function呼叫了A嗎?
因為印出的log只有顯示死在A
很多function都沒加log, 因此完全看不到東西
但關鍵應該是呼叫的那個function傳的記憶體位置
老實說只想到在每個function呼叫A前都加個printf看看兇手是誰
但這樣有點像土法煉鋼
想知道有沒有更聰明的方法知道是哪個function呼叫的
感覺上應該是有方法的
謝謝大家
--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 123.192.66.108
※ 文章網址: https://webptt.com/m.aspx?n=bbs/C_and_CPP/M.1479914917.A.5E9.html
1F：→ Schottky: 我的方法是寫 Macro 把 __FILE__ 和 __LINE__ 傳進來 11/23 23:33
2F：→ Schottky: 再把這兩項加入此 function 的 log 印出來就行了 11/23 23:34
3F：推 stupid0319: 用olly吧 11/23 23:40
4F：推 LPH66: 一樓的方法其實就是自動化你所想到的方法 11/23 23:51
5F：→ LPH66: 如果拿不到 stack trace 的話這不失為一個好方法 11/23 23:52
謝謝大家的回應
當時也有想過傳__FILE__ 和 __LINE__
但讓 A 多傳兩個參數, 感覺每個呼叫的A都要修改
這樣跟前面都加printf好像差不多
而Schottky 意思是像這樣嗎?
// 宣告一個macro 名稱為functionA
#define A(ptr) A2(ptr, __FILE__, __LINE__)
// 原function本體A修改名稱為A2並多傳兩個string
void A2 ( ptr, __FILE__, __LINE__ )
{
printf ( __FILE__, __LINE__ );
}
不知道有沒有誤會
※ 編輯: usanhuang (123.192.66.108), 11/24/2016 00:05:55
6F：推 LPH66: 差不多, 不過函數本身一般參數即可, __FILE__ 用 char* 接 11/24 00:11
7F：→ LPH66: __LINE__ 用 int 接 11/24 00:11
8F：→ LPH66: 函數的參數名自己另外訂, 不能直接用 __FILE__ __LINE__ 11/24 00:12
謝謝各位
大致上了解了
但想到一個問題
這樣的作法等於是讓原本的副程式變為marco
假如有 extern void A ( void*);
這樣應該會有問題
但這邊應該就無法避掉了吧
只能硬修code了?
※ 編輯: usanhuang (123.192.66.108), 11/24/2016 00:27:29
9F：→ Schottky: extern 一般會集中在 header 吧，只需要改一次 11/24 00:41
10F：→ Schottky: 如果同一個 function 的 extern 散落各處，趁這機會修理 11/24 00:41
11F：→ Schottky: 否則現在不出事，將來若改到 prototype 一樣會出事 11/24 00:42
12F：→ firejox: 我習慣會用#直接把macro 轉字串 11/24 01:14
13F：推 firejox: 如果有支援c99的話 也可以用__func___ 11/24 01:18
14F：→ uranusjr: 如果是 glibc 的話直接 backtrace() 印出來就好了 11/24 02:21
15F：→ uranusjr: Windows API 似乎也有 stack inspection 但我是沒用過 11/24 02:22
16F：推 LPH66: 所以我前面就提了拿不到 stack trace 再說, 不然找那個最快 11/24 02:25
17F：→ stupid0319: 如果在副程式中把ESP存起來呢? 11/24 10:33
18F：→ stupid0319: 這樣就知道最後是誰CALL的 11/24 10:33
19F：→ stupid0319: 不是ESP,把call retn的stack返回地址存起來 11/24 10:36
20F：→ LPH66: 這其實就是 stack trace 實際上是怎麼追出來的方法 11/24 17:44
21F：→ LPH66: 配合除錯資訊中哪裡到哪裡是哪個函式就能建構出 trace 了 11/24 17:45
22F：→ LPH66: 但一般程式是不容易抓到這個地方的, 除非對環境很了解 11/24 17:46
23F：→ LPH66: (ie. 能知道要怎麼去找到這個返回地址) 11/24 17:46
24F：→ LPH66: 所以這種東西多半是 runtime 才會/才能提供 11/24 17:47
25F：推 TobyH4cker: VC 的話有這個macro 11/24 22:49
26F：推 flyfoxy: dump file 然後用工具看call stack 11/27 10:37