• <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>
            今天遇到一個比較奇怪的crash問題,這里記錄下。這個crash是由QA設(shè)置了一些不合理的參數(shù)引起的,還好QA當(dāng)時保存了Dump文件,讓我們可以慢慢分析,從而找出代碼中隱藏的問題。
                
            這里先簡單介紹下ATL/WTL里字符串的設(shè)計(jì):
            (1)每個CString都有自己的串頭(內(nèi)含引用計(jì)數(shù),數(shù)據(jù)長度,已分配內(nèi)存長度),緊接著后面是真正的數(shù)據(jù)。
            因?yàn)槭腔谝糜?jì)數(shù),所以相同的多個CString可以共享同一份數(shù)據(jù)。
            struct CStringData
            {
                long nRefs;     // reference count
                int nDataLength;
                int nAllocLength;
                // TCHAR data[nAllocLength]

                TCHAR* data()
                { return (TCHAR*)(this + 1); }
            };


            (2)每個未初始化CString都會指向同一固定的全局?jǐn)?shù)據(jù),內(nèi)部引用計(jì)數(shù)、數(shù)據(jù)長度、已分配內(nèi)存長度、內(nèi)容分別為-1,0,0,0
            // Globals

            // For an empty string, m_pchData will point here
            // (note: avoids special case of checking for NULL m_pchData)
            // empty string data (and locked)
            _declspec(selectany) int rgInitData[] = { -1, 0, 0, 0 };
            _declspec(selectany) CStringData* _atltmpDataNil = (CStringData*)&rgInitData;
            _declspec(selectany) LPCTSTR _atltmpPchNil = (LPCTSTR)(((BYTE*)&rgInitData) + sizeof(CStringData));

            inline CString::CString()
            {
            Init();
            }
            inline void CString::Init()
            { m_pchData = _GetEmptyString().m_pchData; }

            static const CString& __stdcall _GetEmptyString()
            {
            return *(CString*)&_atltmpPchNil;
            }

            (3)字符串析構(gòu)時會檢測是否已經(jīng)分配內(nèi)存,是否其他沒有人用(引用計(jì)數(shù)小于0),都滿足后才會最終釋放內(nèi)存。
            inline CString::~CString()
            //  free any attached data
            {
                if (GetData() != _atltmpDataNil)
                {
                    if (InterlockedDecrement(&GetData()->nRefs) <= 0)
                        delete[] (BYTE*)GetData();
                }
            }

             用Windbg打開Dump文件,輸入!analyze -v 讓它自動分析Crash時的情況,最終發(fā)現(xiàn)Crash在ATL/WTL字符串的析構(gòu)函數(shù)~CString()里的delete語句, 然后我們通過分析傳入?yún)?shù),發(fā)現(xiàn)外部傳入的是一個沒有初始化的CString,既然是沒有初始化的CString,那應(yīng)該都是指向初始字符串的固定內(nèi)存,也就不會滿足條件 if (GetData() != _atltmpDataNil),為什么會跑到里面去呢?

            這里關(guān)鍵原因就是這個CString是跨模塊傳遞過來的,比如你DLL里有個導(dǎo)出函數(shù)void SetValue(CString strValue), 然后你外部Exe傳遞一個未出始化的字符串CString str; SetValue(str); 這時就會Crash。根本原因是因?yàn)閭魅氲淖址窃贓xe里構(gòu)造,但是在DLL里析構(gòu),Exe里的未初始化str指向的是Exe模塊自己的全局初始值Exe!_atltmpDataNil, 而DLL內(nèi)CString的全局初始值是Dll自己的Dll!_atltmpDataNil, 兩者比較當(dāng)然不相等,而后面的if (InterlockedDecrement(&GetData()->nRefs) <= 0)又會把引用計(jì)數(shù)從-1改成-2, 接下來就會試圖delete這塊不是new出來的全局內(nèi)存,當(dāng)然會Crash了。

            這個Bug一直沒有發(fā)現(xiàn)的原因是QA一直設(shè)置的都是有效參數(shù),也就不會引起傳入未初始化的CString的情況,但這次意外卻暴露了我們代碼中隱藏的問題。

            知道了原因,接下來就是如何改了?方法很多,可以用傳引用的方式CString&;也可以傳C方式的字符串LPCTSTR;也可以還是傳CString, 但是在傳之前先做下長度判斷,以確保已經(jīng)出始化。

            另外提醒下如果要在模塊(DLL)之間傳遞內(nèi)存,要確保C/C++運(yùn)行庫要用DLL的方式(MD), 這樣跨模塊new和delete時他們會共享同一個內(nèi)存堆,不同模塊之間相互new和delete才不會有問題。

            測試工程: DllStringTest
            posted on 2012-07-13 21:27 Richard Wei 閱讀(3885) 評論(4)  編輯 收藏 引用 所屬分類: windbg

            FeedBack:
            # re: 跨模塊傳參數(shù)的教訓(xùn)
            2012-07-14 00:42 | 10年碼農(nóng)
            經(jīng)典問題了,MD雖然可以解決,但個人感覺,還是應(yīng)該養(yǎng)成哪里分配哪里釋放的好。跨DLL釋放總不是很好。。  回復(fù)  更多評論
              
            # re: 跨模塊傳參數(shù)的教訓(xùn)[未登錄]
            2012-07-14 07:38 | 123
            又是一個自造輪子引發(fā)的血案……  回復(fù)  更多評論
              
            # re: 跨模塊傳參數(shù)的教訓(xùn)
            2012-07-16 09:28 | zuhd
            我覺得還是傳char *比較保險(xiǎn),不要傳類  回復(fù)  更多評論
              
            # re: 跨模塊傳參數(shù)的教訓(xùn)
            2012-07-16 10:04 | Richard Wei
            @zuhd
            恩,跨模塊返回一個未初始化的CString會有同樣的問題,
            所以跨模塊還是用C語言的字符串方式比較保險(xiǎn)。  回復(fù)  更多評論
              
            伊人久久大香线蕉精品不卡| 精品午夜久久福利大片| 久久精品中文字幕一区| 久久久精品2019免费观看| 国内精品久久久久国产盗摄| 久久精品亚洲AV久久久无码| 久久久青草久久久青草| 狠狠综合久久综合88亚洲| 情人伊人久久综合亚洲| AV狠狠色丁香婷婷综合久久| 欧美黑人激情性久久| segui久久国产精品| 久久精品国产99久久久古代| 成人a毛片久久免费播放| 久久99九九国产免费看小说| 精品免费久久久久国产一区| 久久国产热精品波多野结衣AV| 国产激情久久久久久熟女老人| 久久久久99精品成人片三人毛片 | 国产午夜精品理论片久久影视| 午夜精品久久久久久99热| 亚洲色欲久久久综合网东京热| 久久久女人与动物群交毛片| 色欲久久久天天天综合网| 99久久99久久精品国产片果冻| 日本强好片久久久久久AAA| 国产成人精品久久一区二区三区| 精品久久久久久久无码 | 久久九九全国免费| 漂亮人妻被中出中文字幕久久| 久久99热精品| 91精品国产高清久久久久久io | 久久影院亚洲一区| 青青青青久久精品国产| 国产亚洲综合久久系列| 手机看片久久高清国产日韩| 久久99国内精品自在现线| 久久一区二区三区99| 99久久婷婷国产综合精品草原| 色欲综合久久躁天天躁蜜桃| 国产精品久久久久免费a∨|