posts - 172, comments - 1253, trackbacks - 0

這兩天在寫一些導出類庫，在測試的時候遇到十分詭異的問題，使我遭受痛苦折磨。經驗是寫代碼到處都可能是炸彈，如果不是見多識光還真有可能懷疑計算機或者相信有鬼。

下面來引入問題：
我寫了一個類，需要保存Tooltip信息和一些動態數組信息。結構應該類似下面這樣：

class SOMEDLL_API CSomeDll {

public:

CSomeDll(void);

// TODO: 在此添加您的方法。

~CSomeDll();

TOOLINFO m_ti;

int* pInt;

};

為了說明問題適當調整了一下，實際情況那個動態數組使用的是stl容器，當然不影響問題說明。

這個想法很自然看起來也不可能有錯誤，于是我就做了測試，結果出現了問題。當時由于代碼很多，我一段一段進行了分析，最終發現調用該導出類出的問題。這樣我直接做了這樣的測試：

CSomeDll* pPtr = new CSomeDll;

delete pPtr;

結果錯誤，堆內存毀壞。百思不得其解，開始懷疑stl的分配器導致的問題，修改成自己寫的集合類，仍然有問題。有開始一段一段屏蔽代碼，最終發現只要TOOLINFO后面有動態數組就會導致問題，但是還是沒有找到問題的根本。

開始不相信計算機了，開始懷疑有鬼了。無奈，新建一個win32的helloworld，刪除所有代碼和資源，只剩下winmain，重復上面的new和delete，發現居然沒有問題了。真是見鬼了？？難道預編譯頭都能引起內存問題嗎？？幸好同事zengfanmiao提到stdafx里面的內容讓我突然想起那些定義的宏會不會導致內存分配問題。

查看TOOLINFO的定義：

typedef struct tagTOOLINFOW {

UINT cbSize;

UINT uFlags;

HWND hwnd;

UINT_PTR uId;

RECT rect;

HINSTANCE hinst;

LPWSTR lpszText;

#if (_WIN32_IE >= 0x0300)

LPARAM lParam;

#endif

#if (_WIN32_WINNT >= 0x0501)

void *lpReserved;

#endif

} TTTOOLINFOW, NEAR *PTOOLINFOW, *LPTTTOOLINFOW;

哦，天哪，發現眉目了，果然是這個宏定義導致的。在測試工程里面沒有定義_WIN32_WINNT，而在dll里面定義該宏為0x0501。所以該對象大小在dll比在測試時大4個字節。一旦對dll里面數據進行了修改就會導致越界訪問。這樣在delete的時候，就會報錯。

這個問題在之前就遇到過，但是不知道怎么就巧合避開了。這次終于了解了內幕，寫代碼還真的小心。MS產品線太長，os的維護導致大量結構體存在這樣做法，只能搖頭嘆息，牢記牢記！！！

posted on 2007-07-17 22:12 萬連文閱讀(1984) 評論(4) 編輯收藏引用所屬分類: 亂七八糟

FeedBack:

# re: 導出類使用值得注意的一個問題

2007-07-17 23:13 | sunny

把TOOLINFO m_ti;改成TOOLINFO *m_ti;就可以解決問題了。回復更多評論

# re: 導出類使用值得注意的一個問題

2007-07-18 08:36 | SmartPtr

這中錯誤一不小心就會出現，而且很難調，回復更多評論

# re: 導出類使用值得注意的一個問題

2007-07-18 09:25 | 金慶

導出類要保證類定義DLL內外一致。回復更多評論

# re: 導出類使用值得注意的一個問題

2007-07-18 21:34 | Corner Zhang

這樣做還是會出tts問題的，若CSomeDll是個singleton這種在dll之外new 和 delete才不會出問題，為了避開tts問題可以在dll中加入對CSomeDll創建和銷毀用的導出函數回復更多評論

刷新評論列表

只有注冊用戶登錄后才能發表評論。


相關文章: 幫朋友尋找一個后臺開發我對谷歌的chromium和android發展的看法一些自己的想法，歡迎討論 2010年總結: 停止博客更新臨時備忘設置樹節點高度的一種方法技術回歸01-Windows內存分配工具筆記本顯示器不亮，有人遇見過嗎？？ linux學習一：wchar輸出

網站導航: 博客園 IT新聞 BlogJava 博問 Chat2DB 管理