ACG狂人

其實我更愛姐汁...

導(dǎo)航

<

2025年9月

>

日

一

二

三

四

五

六

31

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

1

2

3

4

5

6

7

8

9

10

11

統(tǒng)計

隨筆 - 26
文章 - 0
評論 - 90
引用 - 0

常用鏈接

留言簿(4)

隨筆分類

隨筆檔案

熟人

狗熊
基友，大基友，游戲小天后，游戲設(shè)計領(lǐng)域的才女
我的召喚獸
召喚獸性奴傻鳥斯巴達(dá) 隨你定位哇咔咔

搜索

閱讀排行榜

評論排行榜

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

今天記錄一下長久以來屢次犯的錯，每次都是換一種方法編碼來繞過這個問題實現(xiàn)功能的，因為這個問題太過隱蔽，導(dǎo)致今天才發(fā)現(xiàn)其中真正的原因...下面進(jìn)行問題描述：

1

std::map<std::string, Value> keyValue; // 在函數(shù)內(nèi)部分配的堆棧對象（局部變量）
2

ReadData(keyValue);// 從dll中導(dǎo)出的函數(shù)
3

keyValue.clear(); // delete中出現(xiàn)assert異常

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

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

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

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

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

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

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

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

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

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

我覺得實際上是你的DLL接口設(shè)計有問題，從來就沒有見到過接口有使用map的，一般接口的定義只使用C語言的接口，遵守資源誰分配誰釋放的原則，如果使用C++的接口的話，比如map，資源的分配釋放就分不清楚了. 回復(fù) 更多評論

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

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

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

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

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

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

但是你這種玩法是問題復(fù)雜化了。回復(fù) 更多評論

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

@你的錯誤是因為dll的std::map跟你這里的std::map不是使用同一份代碼，而是兩份代碼

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

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

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

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

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

刷新評論列表

只有注冊用戶登錄后才能發(fā)表評論。
【推薦】100%開源！大型工業(yè)跨平臺軟件C++源碼提供，建模，組態(tài)！

相關(guān)文章: boost::asio網(wǎng)絡(luò)傳輸錯誤碼的一些實驗結(jié)果（recv error_code） OGRE與MFC的文件系統(tǒng)沖突問題備忘隨筆系列2：內(nèi)存錯誤備忘隨筆系列1：MFC與OGRE聯(lián)姻注意事項關(guān)于MVC PropertySet OperatorStack的一些設(shè)計思考終于完成了自己的模板設(shè)計，初步實現(xiàn)了filter_streambuf，cge項目啟動...... 析構(gòu)過程中內(nèi)存相關(guān)錯誤的絕大多數(shù)原因完成的網(wǎng)絡(luò)數(shù)據(jù)包文檔化封裝MySQL時解決的兩個字符集問題原來靜態(tài)庫是這樣鏈接的

網(wǎng)站導(dǎo)航: 博客園 IT新聞 BlogJava 博問 Chat2DB 管理

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