評論

# re: 析構過程中內存相關錯誤的絕大多數原因 2010-07-01 17:09 陳梓瀚(vczh)

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

# re: 析構過程中內存相關錯誤的絕大多數原因 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: 析構過程中內存相關錯誤的絕大多數原因 2010-07-01 18:48 壞人

dll導出函數 應該是純C的  回復  更多評論   

# re: 析構過程中內存相關錯誤的絕大多數原因[未登錄] 2010-07-01 19:34 路人甲

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

# re: 析構過程中內存相關錯誤的絕大多數原因 2010-07-01 21:15 Forrest

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

# re: 析構過程中內存相關錯誤的絕大多數原因 2010-07-01 21:28 Forrest

@路人甲
有道理  回復  更多評論   

# re: 析構過程中內存相關錯誤的絕大多數原因 2010-07-02 02:18 Mensch88

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

# re: 析構過程中內存相關錯誤的絕大多數原因 2010-07-02 10:33 老安

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

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

# re: 析構過程中內存相關錯誤的絕大多數原因 2010-07-02 12:28 ebencheung

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

嚴重同意上述觀點.template是源代碼級的復用.請勿跨二進制使用.  回復  更多評論   

# re: 析構過程中內存相關錯誤的絕大多數原因 2010-07-08 14:35 釀

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

# re: 析構過程中內存相關錯誤的絕大多數原因 2013-12-26 13:24 smilelittle

這個常見的錯誤，“2010-07-08 14:35 釀”說的對。原因在于dll和exe鏈接了不同基礎lib導致，把它們全部設置成一樣的，就沒問題了。  回復  更多評論