VB.net DLLのメモリリークについて (ID:143370)

名前

ホームページ(ブログ、Twitterなど)のURL (省略可)

本文

> DLLではなく.netアプリとして行うということでしょうか？
> それであればメモリリークするようです
問題箇所は Ping.SendAsnyc であるという仮定で間違い無さそうですね。

> 公開とはどのようなことですか？
VB6 側で WithEvents して使うタイプの DLL ではない、ということです。
今回はイベント通知ではなく、PostMessage で通知しているのですよね。

> DirectCastのおかげか
DirectCast は単に型変換(正確にはキャスト)を行うだけのものなので
その言い方は語弊がありますが、IDisposable.Dispose の呼び出しが
必須であるという点は間違いないかと。

> 万が一受信できないことがあるたびにDisposeができないと思うのですが大丈夫なのでしょうか？
大丈夫ではないので、Netchk クラス自体を Finalize で対処して
備えておく必要があります。いわゆる IDisposable パターンの実装ですね。

> 今回のコードでは obj がローカル変数となっているため
そのコードだと、VB6 側のオブジェクト寿命管理に問題がありませんか?

それと 案2 の Timer 案において、タイマーを用意するのは DLL 側です。
VB6 の Timer コントロールのことではありません(説明不足でしたね…)。

PingCompleted 内で IDisposable.Dispose してはまずいのであれば、
PingCompleted 後に Dispose するために、System.Threading.Timer 等で
遅延処理させるというのが案2です。ただし PingCompleted 内で解放しても
先のエラー問題が再現しないのなら、その必要は無さそうですけれども。

> 8k増加しつづけているようです。
その実装(VB6 側で Timer を使っているサンプル)は、
そもそも別の問題があるので除外して…。

当初のコードにおいて、IDisposable.Dispose 以外の解放処理を
必要とするとなれば、あと思いつくのは、PingCompleted 完了時に 
RemoveHandler を呼び出してイベントを解除することと、
フィールド変数である mainPing に Nothing を代入して、
GC の回収対象にされやすくすることぐらいですかね。

ただ、これらは通常気にする必要は無いと思うので、
IDisposable.Dispose のような明確な効果は得られないかもしれません。

> あとはVB2010にすると解消する等のことも考えられますか？
気にするべきは VB のバージョンではなく .NET Framework のバージョンです。

既に何度か書いたように、「.NET 4 や .NET 4.5 版の Ping クラス」では
Dispose が適切に実装されているため、IDisposable.Dispose であろうと
Ping.Dispose であろうと、どちらの呼び方でも問題ないと思われます。

また、万一 Dispose の呼び出しを忘れても Finalize によって
GC 回収時に自動破棄されることが期待されます。

なので、VB2012 や VB2010 を使えば、問題点を解消できる可能性は
ありますが、これらのバージョンでも、ターゲットフレームワークに
.NET 2.0〜3.5 を採用した場合はやはり IDisposable.Dispose を
明示的に呼び出すという、同様の対策が要求されることになるでしょう。

←解決時は質問者本人がここをチェックしてください。

戻る