• <ins id="pjuwb"></ins>
    <blockquote id="pjuwb"><pre id="pjuwb"></pre></blockquote>
    <noscript id="pjuwb"></noscript>
          <sup id="pjuwb"><pre id="pjuwb"></pre></sup>
            <dd id="pjuwb"></dd>
            <abbr id="pjuwb"></abbr>
            萬星星@豌豆莢 歡迎加入我們
            一個吃軟飯的男人!!!!!我只想寫程序####
            微博:http://weibo.com/wanlianwen
            posts - 172,  comments - 1253,  trackbacks - 0
            這兩天在寫一些導出類庫,在測試的時候遇到十分詭異的問題,使我遭受痛苦折磨。經驗是寫代碼到處都可能是炸彈,如果不是見多識光還真有可能懷疑計算機或者相信有鬼。

            下面來引入問題:
            我寫了一個類,需要保存Tooltip信息和一些動態(tài)數組信息。結構應該類似下面這樣:
            class SOMEDLL_API CSomeDll {
            public:
                CSomeDll(
            void);
                
            // TODO: 在此添加您的方法。
                ~CSomeDll();

                TOOLINFO m_ti;
                
            int* pInt;
            }
            ;
            為了說明問題適當調整了一下,實際情況那個動態(tài)數組使用的是stl容器,當然不影響問題說明。


            這個想法很自然看起來也不可能有錯誤,于是我就做了測試,結果出現了問題。當時由于代碼很多,我一段一段進行了分析,最終發(fā)現調用該導出類出的問題。這樣我直接做了這樣的測試:
            CSomeDll* pPtr = new CSomeDll;
                delete pPtr;
            結果錯誤,堆內存毀壞。百思不得其解,開始懷疑stl的分配器導致的問題,修改成自己寫的集合類,仍然有問題。有開始一段一段屏蔽代碼,最終發(fā)現只要TOOLINFO后面有動態(tài)數組就會導致問題,但是還是沒有找到問題的根本。

            開始不相信計算機了,開始懷疑有鬼了。無奈,新建一個win32的helloworld,刪除所有代碼和資源,只剩下winmain,重復上面的new和delete,發(fā)現居然沒有問題了。真是見鬼了??難道預編譯頭都能引起內存問題嗎??幸好同事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;

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

            這個問題在之前就遇到過,但是不知道怎么就巧合避開了。這次終于了解了內幕,寫代碼還真的小心。MS產品線太長,os的維護導致大量結構體存在這樣做法,只能搖頭嘆息,牢記牢記?。?!
            posted on 2007-07-17 22:12 萬連文 閱讀(1964) 評論(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創(chuàng)建和銷毀用的導出函數  回復  更多評論
              
            簡歷下載
            聯系我

            <2008年11月>
            2627282930311
            2345678
            9101112131415
            16171819202122
            23242526272829
            30123456

            常用鏈接

            留言簿(66)

            隨筆分類

            隨筆檔案

            相冊

            搜索

            •  

            最新評論

            閱讀排行榜

            評論排行榜

            亚洲国产二区三区久久| 久久国产精品二国产精品| 国产精品久久久久久久人人看| 精品视频久久久久| 国产91色综合久久免费分享| 很黄很污的网站久久mimi色| 久久伊人亚洲AV无码网站| 亚洲AV日韩AV天堂久久| 日本精品久久久久中文字幕8| 99久久国产热无码精品免费| 久久国产精品国产自线拍免费| 国产成人久久激情91| 狠狠人妻久久久久久综合蜜桃| 久久综合九色综合久99| 午夜久久久久久禁播电影| 国产国产成人久久精品| 青草国产精品久久久久久| 国产69精品久久久久777| 精品久久久一二三区| 国产精自产拍久久久久久蜜| 久久久久亚洲AV片无码下载蜜桃 | 模特私拍国产精品久久| 久久久无码精品亚洲日韩按摩| 国产精品青草久久久久福利99| 久久亚洲AV无码精品色午夜麻豆 | 无码任你躁久久久久久| 亚洲国产精品无码久久一线| 99久久国产热无码精品免费久久久久| 久久精品中文字幕一区| 国产99久久久国产精免费| 久久久久青草线蕉综合超碰| 精品久久久久久无码免费| 久久精品视频网| 久久96国产精品久久久| 久久国产精品成人影院| 午夜天堂精品久久久久| 亚洲综合伊人久久大杳蕉| 伊人久久大香线蕉av一区| 国产精品中文久久久久久久| 久久久久亚洲AV无码专区首JN | 日本久久久久久中文字幕|