2012-07-09 62 views
0

我有以下情況:如何處理從.net泄漏的第三方庫?

我正在使用第三方.net庫調用非託管代碼來執行所需的操作(.net的東西只是一個薄包裝)。該庫有各種各樣的IDisposable實現等,我正在使用它包裝,但它仍然像內存泄漏一樣,錯誤,篩我想(我已經能夠在單元測試中證實這一點)。

理想的情況下,當然我會得到第三方來解決他們的圖書館,但他們都沒有反應,我很遺憾,不能刪除,要麼等什麼我目前做的是這個...

的工作,我我正在用這個第三方庫做的事情可以很容易地封裝起來,所以我需要它的時候我會啓動一個包含一些命令行參數的進程,並將其標準化。該過程完成它需要做的事情,並通過簡單地將它序列化到標準來返回一個結果對象,然後啓動應用程序中的方法啓動該過程,將結果對象反序列化並返回它,就像沒有發生任何異常事件一樣。

很明顯,這是非常icky(命令行參數解析,序列化等所有增加複雜性和放緩東西),但它的優點是它非常簡單,它的工作原理(幸運的是,你甚至可以關閉窗口CreateNoWindow,這樣應用程序的用戶也不會注意到任何不適)。

其他方法我想過:

  • 卸載應用程序池和諸如此類的東西,但因爲被泄漏.NET之外被分配的內存我估計可能不會幫助或者將它?
  • 我也看着試圖卸載DLL,但它看起來充滿危險 - 我可以安全可靠地做到這一點嗎?

所以,我的問題基本上可以歸結爲...

有沒有辦法,我可以把一切都在過程中,不知何故清理這個第三方庫爲它的底部的方式,所以我不漏記憶?

+0

什麼內存泄露的究竟?如果你能找到泄漏的指針,你可以自己釋放它。 – leppie 2012-07-09 08:57:19

+0

只是好奇,如果它只是簡單地通過stdin/stdout接口封裝,爲什麼它不可替代? (我經歷過很多次與第三方組件開發人員類似的煩惱,我真的試圖避開它們,除非它們被證明是響應式的或提供源代碼)。 – silijon 2012-07-09 09:00:34

+0

有趣,謝謝。關鍵是我沒有任何指針訪問權限 - 它將事物包裝到.Net對象集合中,並正式返回這些對象,我只能訪問這些對象的公共表面。在內部,我相信他們可能有IntPtrs一堆和諸如此類的東西左右所以也許我可以挖掘到它與反射器的代碼,並找出它到底是什麼做的,然後使用反射來獲取潛在的IntPtr的保持和免費這一點,但因爲我不「知道什麼他們的非託管代碼是做那種感覺決然冒險 – kmp 2012-07-09 09:02:38

回答

1

......它仍然像內存泄漏,錯誤,篩我想(我已經能夠在單元測試中證實這一點)。

我假設的答案是「不」,但我要問 - 是有它在正常使用「泄漏」內存 任何機會,但非常聰明地清理這一切,當你「關掉它」?我至少遇到了一些庫,它們的內部緩存似乎以無限制的方式增長,但是在庫的終止例程被調用時會被清除。

假定泄漏是真的只是錯誤,然後...

...我需要它,我發起一個進程,一對夫婦的命令行參數,並捕獲標準輸出

......我認爲你的方法是最合理的,因爲情況的參數。實際上,您託管的代碼不「信任」 - 可能不是出於安全原因,而是出於性能/可靠性原因。

卸載應用程序池和whatnot,但因爲泄漏的內存是分配在.net之外我想這可能不會幫助或將它?

正確的 - 這不會幫助。

我也看着試圖卸載DLL,但它看起來有點充滿危險 - 我可以安全可靠地做到這一點嗎?

,最有可能不會解決問題。如果代碼與您所說的一樣錯誤,那麼在卸載時清理其分配的資源很可能不太合適。 (系統不會爲它清理其資源 - 如果它分配了一個資源而沒有釋放資源,則該資源將會有效泄漏。)

在這種情況下,您確實沒有太多的工作要做。我能想到的唯一的最後一種選擇是試圖鉤住/攔截第三方庫的例程,以某種方式將其所有分配強制到一個池中,您可以一次釋放所有資源(釋放庫之後)。 但你真的不應該這樣做。這是相當危險的,幾乎肯定就得不償失了,太難正確執行等

+0

感謝您的回答 - 是的,您的問題的答案確實不是:-(看起來我會堅持我的rope approach方法! – kmp 2012-07-09 09:14:27