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 を 明示的に呼び出すという、同様の対策が要求されることになるでしょう。