• <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>

            ACG狂人

            其實(shí)我更愛(ài)姐汁...

            析構(gòu)過(guò)程中內(nèi)存相關(guān)錯(cuò)誤的絕大多數(shù)原因

            今天記錄一下長(zhǎng)久以來(lái)屢次犯的錯(cuò),每次都是換一種方法編碼來(lái)繞過(guò)這個(gè)問(wèn)題實(shí)現(xiàn)功能的,因?yàn)檫@個(gè)問(wèn)題太過(guò)隱蔽,導(dǎo)致今天才發(fā)現(xiàn)其中真正的原因...下面進(jìn)行問(wèn)題描述:
            1std::map<std::string, Value> keyValue; // 在函數(shù)內(nèi)部分配的堆棧對(duì)象(局部變量)
            2ReadData(keyValue);// 從dll中導(dǎo)出的函數(shù)
            3keyValue.clear(); // delete中出現(xiàn)assert異常

            第一行是在應(yīng)用程序中的堆棧中分配的內(nèi)存空間。
            第二行是我自己寫(xiě)的dll庫(kù),用來(lái)讀取一些數(shù)據(jù)加入到keyValue中。
            第三行是清空keyValue,其實(shí)如果不寫(xiě)這一行的話,keyValue也會(huì)在函數(shù)結(jié)尾時(shí)清空,到那時(shí)同樣會(huì)出現(xiàn)錯(cuò)誤。
            這一切乍一看沒(méi)啥問(wèn)題,keyValue是局部變量,為什么局部變量的釋放會(huì)出現(xiàn)異常錯(cuò)誤呢?這是因?yàn)榈诙蠷eadData的緣故。ReadData的邏輯在另外一個(gè)可執(zhí)行模塊中,在其中分配的內(nèi)存空間不一定與當(dāng)前模塊在同一個(gè)堆區(qū)。
            我們知道,std::map是一個(gè)樹(shù)結(jié)構(gòu)的容器,我在ReadData內(nèi)部往keyValue中添加了數(shù)據(jù),keyValue中會(huì)在堆區(qū)中分配樹(shù)節(jié)點(diǎn),而這個(gè)節(jié)點(diǎn)將會(huì)在當(dāng)前模塊在keyValue的析構(gòu)中被釋放。也就是說(shuō),我無(wú)意中在dll模塊中分配了堆空間,又無(wú)意中在exe模塊中企圖釋放該空間,這樣的行為導(dǎo)致錯(cuò)誤是不足為怪的。
            時(shí)刻牢記,在一個(gè)模塊中分配和釋放同一塊內(nèi)存區(qū)域,警惕你所看不見(jiàn)的內(nèi)存分配和釋放。

            posted on 2010-07-01 15:47 釀妹汁 閱讀(3359) 評(píng)論(11)  編輯 收藏 引用 所屬分類: C++備忘

            評(píng)論

            # re: 析構(gòu)過(guò)程中內(nèi)存相關(guān)錯(cuò)誤的絕大多數(shù)原因 2010-07-01 17:09 陳梓瀚(vczh)

            你的錯(cuò)誤是因?yàn)閐ll的std::map跟你這里的std::map不是使用同一份代碼,而是兩份代碼。所以不要拿stl的模板容器去跨dll。所以這種時(shí)候,你應(yīng)該去包裝一個(gè)不能再.h看到實(shí)現(xiàn)的StringValueMap然后暴露出來(lái),或者不要用dll直接使用它的代碼。  回復(fù)  更多評(píng)論   

            # re: 析構(gòu)過(guò)程中內(nèi)存相關(guān)錯(cuò)誤的絕大多數(shù)原因 2010-07-01 18:30 hxhxd

            看到了dll導(dǎo)出了一個(gè)wrap std::string 的std:map,嚴(yán)重懷疑std:string的copy-on-write 使得兩個(gè)模塊引用了同一個(gè)stringbuffer,然后dll模塊的unload或者exe模塊的clear都有可能導(dǎo)致對(duì)方模塊在進(jìn)一步的操作中access violation.  回復(fù)  更多評(píng)論   

            # re: 析構(gòu)過(guò)程中內(nèi)存相關(guān)錯(cuò)誤的絕大多數(shù)原因 2010-07-01 18:48 壞人

            dll導(dǎo)出函數(shù) 應(yīng)該是純C的  回復(fù)  更多評(píng)論   

            # re: 析構(gòu)過(guò)程中內(nèi)存相關(guān)錯(cuò)誤的絕大多數(shù)原因[未登錄](méi) 2010-07-01 19:34 路人甲

            本人喜歡鉆牛角尖,博主能否把測(cè)試代碼發(fā)給我(alcoholyi@qq.com)。
            另外,你下的結(jié)論有誤,沒(méi)有什么exe,dll模塊堆空間一說(shuō),堆只跟進(jìn)程有關(guān)系,可以簡(jiǎn)單的理解為同一個(gè)進(jìn)程的dll和exe共享一個(gè)堆空間。
              回復(fù)  更多評(píng)論   

            # re: 析構(gòu)過(guò)程中內(nèi)存相關(guān)錯(cuò)誤的絕大多數(shù)原因 2010-07-01 21:15 Forrest

            我覺(jué)得實(shí)際上是你的DLL接口設(shè)計(jì)有問(wèn)題,從來(lái)就沒(méi)有見(jiàn)到過(guò)接口有使用map的,一般接口的定義只使用C語(yǔ)言的接口,遵守資源誰(shuí)分配誰(shuí)釋放的原則,如果使用C++的接口的話,比如map,資源的分配釋放就分不清楚了.  回復(fù)  更多評(píng)論   

            # re: 析構(gòu)過(guò)程中內(nèi)存相關(guān)錯(cuò)誤的絕大多數(shù)原因 2010-07-01 21:28 Forrest

            @路人甲
            有道理  回復(fù)  更多評(píng)論   

            # re: 析構(gòu)過(guò)程中內(nèi)存相關(guān)錯(cuò)誤的絕大多數(shù)原因 2010-07-02 02:18 Mensch88

            完全贊同vczh的觀點(diǎn)。lz的ReadData肯定是在另一個(gè)庫(kù)里面編譯的,而那個(gè)庫(kù)調(diào)用的STL lib與現(xiàn)在的項(xiàng)目不同。這跟模塊沒(méi)有任何關(guān)系。
            我最近也一直碰到這種情況。使用別人的第三方程序庫(kù),Release能跑,而Debug里面一碰到傳遞string就出錯(cuò)。郁悶。
            有誰(shuí)知道如何能查看第三方庫(kù)到底link了哪些dll么?
              回復(fù)  更多評(píng)論   

            # re: 析構(gòu)過(guò)程中內(nèi)存相關(guān)錯(cuò)誤的絕大多數(shù)原因 2010-07-02 10:33 老安

            確實(shí)有一種情況,
            在window下遇到過(guò),兩個(gè)dll,在其中一個(gè)dll中new一個(gè)object,然后在另外一個(gè)dll delete,崩潰。
            環(huán)境是winxp vc6.
            很久之前了。

            但是你這種玩法是問(wèn)題復(fù)雜化了。  回復(fù)  更多評(píng)論   

            # re: 析構(gòu)過(guò)程中內(nèi)存相關(guān)錯(cuò)誤的絕大多數(shù)原因 2010-07-02 12:28 ebencheung

            @你的錯(cuò)誤是因?yàn)閐ll的std::map跟你這里的std::map不是使用同一份代碼,而是兩份代碼

            嚴(yán)重同意上述觀點(diǎn).template是源代碼級(jí)的復(fù)用.請(qǐng)勿跨二進(jìn)制使用.  回復(fù)  更多評(píng)論   

            # re: 析構(gòu)過(guò)程中內(nèi)存相關(guān)錯(cuò)誤的絕大多數(shù)原因 2010-07-08 14:35

            回LS幾位的話...釋放內(nèi)存的時(shí)候,系統(tǒng)提示為已經(jīng)釋放過(guò)的內(nèi)存塊或是在不同的堆中分配的內(nèi)存。也許提示的不正確,但是本著誰(shuí)分配誰(shuí)釋放的原則的話,就算在模塊接口上使用std的容器也應(yīng)該沒(méi)什么問(wèn)題。
            這方面只要注意在兩個(gè)模塊中使用同樣的clib鏈接方式就可以,分為debug、release、static、dynamic的命名方式,項(xiàng)目中存在多種配置,都是統(tǒng)一的。  回復(fù)  更多評(píng)論   

            # re: 析構(gòu)過(guò)程中內(nèi)存相關(guān)錯(cuò)誤的絕大多數(shù)原因 2013-12-26 13:24 smilelittle

            這個(gè)常見(jiàn)的錯(cuò)誤,“2010-07-08 14:35 釀”說(shuō)的對(duì)。原因在于dll和exe鏈接了不同基礎(chǔ)lib導(dǎo)致,把它們?nèi)吭O(shè)置成一樣的,就沒(méi)問(wèn)題了。  回復(fù)  更多評(píng)論   

            婷婷久久综合九色综合绿巨人 | 无码人妻精品一区二区三区久久 | 久久久噜噜噜www成人网| 无码人妻精品一区二区三区久久久 | 久久综合成人网| 久久精品国产亚洲av影院| 久久综合九色综合久99| 久久99热这里只频精品6| 国产国产成人精品久久| 久久综合九色欧美综合狠狠| 新狼窝色AV性久久久久久| 久久久久久久综合日本| 精品熟女少妇a∨免费久久| 日日狠狠久久偷偷色综合免费| 无遮挡粉嫩小泬久久久久久久 | 天天综合久久久网| 亚洲中文字幕久久精品无码APP| 777久久精品一区二区三区无码| 精产国品久久一二三产区区别| 久久精品国产免费一区| 久久无码AV中文出轨人妻| 狠狠色丁香婷婷综合久久来来去| 久久久久国产精品熟女影院| 思思久久好好热精品国产| 人人狠狠综合久久亚洲| 国产精品成人久久久久三级午夜电影 | 国内精品久久久久影院亚洲| 久久www免费人成精品香蕉| 久久久久免费看成人影片| 久久国产劲爆AV内射—百度| 久久久久亚洲精品男人的天堂| 97久久精品人人做人人爽| 东京热TOKYO综合久久精品| 日本久久久久亚洲中字幕| 精品久久亚洲中文无码| 久久精品国产清自在天天线| 久久亚洲国产最新网站| 久久久久国产精品嫩草影院| 久久亚洲国产精品成人AV秋霞| 模特私拍国产精品久久| 久久久国产打桩机|