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

            其實我更愛姐汁...
            

            




            
	
					
	
            
		
            
			析構(gòu)過程中內(nèi)存相關(guān)錯誤的絕大多數(shù)原因
		
            
		今天記錄一下長久以來屢次犯的錯，每次都是換一種方法編碼來繞過這個問題實現(xiàn)功能的，因為這個問題太過隱蔽，導致今天才發(fā)現(xiàn)其中真正的原因...下面進行問題描述：
            

            1std::map<std::string, Value> keyValue; // 在函數(shù)內(nèi)部分配的堆棧對象（局部變量）
            2ReadData(keyValue);// 從dll中導出的函數(shù)
            3keyValue.clear(); // delete中出現(xiàn)assert異常
            

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

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





            
	    
    


            

            評論
            
	
	
			
            
				# re: 析構(gòu)過程中內(nèi)存相關(guān)錯誤的絕大多數(shù)原因
					
						2010-07-01 17:09
					
				陳梓瀚(vczh)
			
            
			
            
				你的錯誤是因為dll的std::map跟你這里的std::map不是使用同一份代碼，而是兩份代碼。所以不要拿stl的模板容器去跨dll。所以這種時候，你應該去包裝一個不能再.h看到實現(xiàn)的StringValueMap然后暴露出來，或者不要用dll直接使用它的代碼。  回復  更多評論
				  
			
            
		
			
            
				# re: 析構(gòu)過程中內(nèi)存相關(guān)錯誤的絕大多數(shù)原因
					
						2010-07-01 18:30
					
				hxhxd
			
            
			
            
				看到了dll導出了一個wrap std::string 的std:map,嚴重懷疑std:string的copy-on-write 使得兩個模塊引用了同一個stringbuffer,然后dll模塊的unload或者exe模塊的clear都有可能導致對方模塊在進一步的操作中access violation.  回復  更多評論
				  
			
            
		
			
            
				# re: 析構(gòu)過程中內(nèi)存相關(guān)錯誤的絕大多數(shù)原因
					
						2010-07-01 18:48
					
				壞人
			
            
			
            
				dll導出函數(shù) 應該是純C的  回復  更多評論
				  
			
            
		
			
            
				# re: 析構(gòu)過程中內(nèi)存相關(guān)錯誤的絕大多數(shù)原因[未登錄]
					
						2010-07-01 19:34
					
				路人甲
			
            
			
            
				本人喜歡鉆牛角尖，博主能否把測試代碼發(fā)給我(alcoholyi@qq.com)。

            另外，你下的結(jié)論有誤，沒有什么exe,dll模塊堆空間一說，堆只跟進程有關(guān)系，可以簡單的理解為同一個進程的dll和exe共享一個堆空間。

              回復  更多評論
				  
			
            
		
			
            
				# re: 析構(gòu)過程中內(nèi)存相關(guān)錯誤的絕大多數(shù)原因
					
						2010-07-01 21:15
					
				Forrest
			
            
			
            
				我覺得實際上是你的DLL接口設(shè)計有問題，從來就沒有見到過接口有使用map的，一般接口的定義只使用C語言的接口，遵守資源誰分配誰釋放的原則，如果使用C++的接口的話，比如map，資源的分配釋放就分不清楚了.  回復  更多評論
				  
			
            
		
			
            
				# re: 析構(gòu)過程中內(nèi)存相關(guān)錯誤的絕大多數(shù)原因
					
						2010-07-01 21:28
					
				Forrest
			
            
			
            
				@路人甲
            有道理  回復  更多評論
				  
			
            
		
			
            
				# 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么？
              回復  更多評論
				  
			
            
		
			
            
				# re: 析構(gòu)過程中內(nèi)存相關(guān)錯誤的絕大多數(shù)原因
					
						2010-07-02 10:33
					
				老安
			
            
			
            
				確實有一種情況，
            在window下遇到過，兩個dll，在其中一個dll中new一個object，然后在另外一個dll delete，崩潰。
            環(huán)境是winxp vc6.
            很久之前了。

            但是你這種玩法是問題復雜化了。  回復  更多評論
				  
			
            
		
			
            
				# re: 析構(gòu)過程中內(nèi)存相關(guān)錯誤的絕大多數(shù)原因
					
						2010-07-02 12:28
					
				ebencheung
			
            
			
            
				@你的錯誤是因為dll的std::map跟你這里的std::map不是使用同一份代碼，而是兩份代碼

            嚴重同意上述觀點.template是源代碼級的復用.請勿跨二進制使用.  回復  更多評論
				  
			
            
		
			
            
				# 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的容器也應該沒什么問題。
            這方面只要注意在兩個模塊中使用同樣的clib鏈接方式就可以，分為debug、release、static、dynamic的命名方式，項目中存在多種配置，都是統(tǒng)一的。  回復  更多評論
				  
			
            
		
			
            
				# re: 析構(gòu)過程中內(nèi)存相關(guān)錯誤的絕大多數(shù)原因
					
						2013-12-26 13:24
					
				smilelittle
			
            
			
            
				這個常見的錯誤，“2010-07-08 14:35 釀”說的對。原因在于dll和exe鏈接了不同基礎(chǔ)lib導致，把它們?nèi)吭O(shè)置成一樣的，就沒問題了。  回復  更多評論
				  
			
            
		

            




            






            

				

            


    
    







            
	   
	



色综合久久久久综合体桃花网|
久久露脸国产精品|
久久久久免费精品国产|
国产精品99久久久精品无码|
精品一区二区久久|
亚洲精品成人网久久久久久|
亚洲国产精品无码久久一线|
97久久精品人人做人人爽|
久久久久久国产精品美女|
国产精品伦理久久久久久|
久久WWW免费人成一看片|
97久久精品人人做人人爽|
久久精品中文字幕大胸|
久久99精品久久只有精品|
久久午夜综合久久|
久久久久四虎国产精品|
狠狠综合久久综合88亚洲|
久久久久无码中|
久久精品人人做人人爽电影|
一本色道久久99一综合|
中文成人无码精品久久久不卡|
一本大道加勒比久久综合|
丁香色欲久久久久久综合网|
91久久成人免费|
久久精品这里热有精品|
久久99精品久久久久久hb无码|
久久人人爽人人爽人人片AV不|
亚洲精品综合久久|
久久福利片|
久久国产福利免费|
91精品国产91久久久久久青草|
狠狠色丁香久久综合婷婷|
久久精品aⅴ无码中文字字幕不卡|
热久久国产欧美一区二区精品
|
久久精品国产一区二区三区不卡
|
一97日本道伊人久久综合影院|
久久青草国产精品一区|
91久久福利国产成人精品|
伊人热人久久中文字幕|
久久久WWW成人免费毛片|
狠狠色丁香久久婷婷综合蜜芽五月
|