リソースリーク対策
■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさん
NGNGチェック機能でかなりの部分を発見できるけれど、
GDI等のリソースリークはどのようにチェックしていますか？
NumegaやRationalのツールを使えばわかるけれど、ライセンス高価だし、
手軽に出来て、効果が期待できる方法ってないでしょうか
0044デフォルトの名無しさん
NGNGタスクトレイにアイコン突っ込みまくるプログラムを作れば
そのうちExplorerが落ちるってことですね。チャレンジしてみます。
0045デフォルトの名無しさん
NGNG間違ってやったら途中で(120個位)起動できなくなった覚えあり(Win2000)
0046トリッキーの１
NGNGさて、面白い事を発見。Win9X系では、DeleteObjectの挙動が不穏です。
この関数は成功すればtrueを返すんだけれど、例えば
....
SelectObject(hMemDC,hBitmap);
....
BOOL b=DeleteObject(hBitmap);
ReleaseDC(hDC);
とかやると、ここでhBitmapの削除に失敗し
リソースリークが発生するにも関わらず、
なぜかb==1になってしまうのです。
と言うわけで、Purifyでも検出出来ませんでした（元々NT用だから話が違うけれど）。
これを検出するにはどうすればいいんだろう？
……今思いついたが、２回DeleteObjectをやってみるのは手かも知れない。
0047デフォルトの名無しさん
NGNG不穏なのは既出
http://www.microsoft.com/JAPAN/support/kb/articles/J024/2/17.htm?LN=JA&SD=SO&FR=0
> Windows 95 では、SeleteObject() で DC に選択されているときに GDI
> 描画オブジェクトを削除しようとすると DeleteObject() への呼び出しが
> 正常終了します。
>
> しかし呼び出しが正常に終了しても実際には削除されていません。Windows NT
> では DC に選択された GDI オブジェクトで DeleteObject() への呼び出しを
> 行うと失敗します。 DeleteObject を呼び出す前には GDI オブジェクトの
> 選択を常にクリアする必要があります。
0048トリッキーの１
NGNGじゃ、NT系列でDeleteObjectの正否をチェックするか、
9xでDeleteObjectの複数成功をチェックするか、どちらかですね。
普通メモリリークを追跡する場合の開発環境は9x系列のはずなので、
後者の方向でチェックツール開発を進めてみます。
004931
NGNG既にある大量のソース群ですか...
だったらマクロ使って自分で作った派生クラスを通すようにするのじゃダメ？
例えば、
#if _DEBUG // デバッグ時のみチェック
#define CDC CUserDC
#define CBrush CUserBrush
#endif
とする。
そんでCUserDCでどのオブジェクトが選択されているか、CUserBrushで
どのDCから選択されているかを記録しておく。
そうすればDCを開放する時に選択済みオブジェクトがあれば、非選択にした後に
開放できるんじゃないかと思った。
どうでしょう？
補足：DeleteObject()の戻り値を確実にチェックしておけばリークが見つかるんだけどね。
0051デフォルトの名無しさん
NGNG0052デフォルトの名無しさん
NGNG0053デフォルトの名無しさん
NGNGハイハイ、自分の技術力の無さを認めたわけね。
ある意味潔くていいよ。
0054！！！警告！！！
NGNG0055デフォルトの名無しさん
NGNG0056トリッキーの１
NGNGやはり当然、オンザフライで警告を出したい。
>>51
マジレスすれば、C#を使えばこの種の問題は無くなる。
しかもJavaのように速度がネックになることも無い。
しかし汎用性は無くなる。まぁこの場合Windows特化なので
汎用性は話の外だからいいけどね
0057デフォルトの名無しさん
NGNG0058デフォルトの名無しさん
NGNG0059デフォルトの名無しさん
NGNGサーバサイドで Singleton のコレクションにオブジェクトがんがん
突っ込んで削除しない VB 厨房上がりが多いんだが。
0060デフォルトの名無しさん
NGNG0061デフォルトの名無しさん
NGNG0062デフォルトの名無しさん
NGNGJavaって、streamのclose()を呼び忘れてると、finalizeされるまで
システムリソース(fdやsocket)を握ったままになりますね。マヌケです。
強制GCすればいいんですが、GCでfinalizeされるとは規定されてないし、
結構厄介だと思います。だけどJava最高！！！
0063デフォルトの名無しさん
NGNGというわけで、案外API拡張はまともなアイデアかもしれません
しかしモジュールごとにフックする必要がなぜあるのかわかりません。
APIって皆同じコードが呼ばれているんじゃないの？
0064デフォルトの名無しさん
NGNG0065デフォルトの名無しさん
NGNGもう古いよ。
0066デフォルトの名無しさん
NGNG006731
NGNG#if _DEBUG // デバッグ時のみチェック
#define SelectObject UserSelectObject
#define DeleteObject UserObjectDC
#define DeleteDC UserDeleteDC
#define ReleaseDC UserReleaseDC
#endif
あとはCreatePenとかのオブジェクト作成関数もラッパすれば完全では？
つか、この手のものは１本ソース書いておけばいろんなプロジェクトで使いまわしできるんだし、
身の回りの誰かが作っていたりして。
0068トリッキーの１
NGNGそれだと、
CDC *pDC;
..
pDC->SelectObject(hBrush); // アウト
0069デフォルトの名無しさん
NGNG>>66
ええ、そのとおりです。メモリーリークでなく「リソース」リークですね。
実行中のリソース解放し忘れは、Javaであっても鬼門なんです。
なんせgc/finalizeの実装に依存しちゃいますからね！でもJava最高！
0070デフォルトの名無しさん
NGNGのスーパークラスを作ったおかげでリソースリークでまくりです。
30 分も動かしているとアプリケーションとまっちゃいます。
うんこ。
うんこ。
007170
NGNGひどく疲れているようだ...
0072デフォルトの名無しさん
NGNGどちらかというと> うんこ。を二つも書く辺りに取り返しのつかない疲労を感じる
0073デフォルトの名無しさん
NGNGCUserDC:CUserSelectObjectになっちゃいます
この方向のアプローチはデバッグ版ではリークしないのにリリース版で
リークするという現象が発生したときどうにもならないし
0074デフォルトの名無しさん
NGNG>>56 (C#)
>しかもJavaのように速度がネックになることも無い。
これ本当ですか？何故そうなるっすか？Javaとそんなに違うっすか？
0075デフォルトの名無しさん
NGNG話題沸騰中の頃のセールストークだよ。それを信じたまま今日まで来てる C/C++
信者多すぎ。
0076デフォルトの名無しさん
NGNGC/C++信者 → MS信者
Javaの、まだモノも出来てない話題沸騰中の頃のセールストークも酷かったねえ...
0077デフォルトの名無しさん
NGNG0078トリッキーの１
NGNGスレ違いだけれどちょっと確認させてください。
セールストークとβ版によれば、
・VMを介しないのでコードが高速（利点）
・標準ライブラリが充実（必須）
・ネイティブコード依存（欠点）
なので、クロスプラットフォームが多少関わるWeb系は今まで通りJavaで、
Windows系のGUIプログラムはC#に移行していく、と思われます。
Javaを使い続ける限り、どんなにCPUが高速になったところで、
速度で「VMを介する」というネックを避けることが出来ないので、
Windowsネイティブに限ればC#で開発するメリットは非常に大きいでしょう。
しかし、速度よりも移植性が大事なWeb系のプログラミングでは、
IISでしか使えないであろうC#にわざわざ乗り換える人も少ないでしょう。
（仮にLinux上などで環境が整えば、一気にC#の価値が高まるでしょうね）
コレについて、具体的に「この点が違うよ」というのがあれば教えてください。
この話題についてはsage進行でいきませう。
0079ななＣ#
NGNG最適化については、直感的にC#の方が優れているような。
言語の歴史では明らかにＣの方が長いし、
C#とJavaは同じ最適化理論を使える（オブジェクト言語最適化）し、
歴史的にＭＳは開発環境だけはいいものを提供してくれるし。
C#が低速というのは、実験した結果？だとするとそうかもしれないけど。
ま、製品版がリリースされるまで解らないな
0080デフォルトの名無しさん
NGNG> ・VMを介しないのでコードが高速（利点）
CLRってのはVMだろ。
0081トリッキーの１
NGNGこんな知識でＣ＃について語る資格はありませんね。
ごめんなさい。
しかしまぁ、Javaの様な汎用的なVMではなく、
Windowsに特化したVMして速度改善を達成するのでは、と
思われるのですが、その情報をご存じの方は？
というか、やっぱりＣ＃はＣ＃スレでやるべきですね。
このスレで不用意なＣ＃の発言をしてしまい、結果荒らしてしまいすみません＞１さん
008231
NGNGMFCじゃなくてAPIの場合の話だったのに...
ちなみに「漏れなくラッパする」って考え自体がまずいの？
>>73
デバッグ版とリリース版で動作が違う時ってどんな場合があったっけ？
変数の未初期化での使用とか配列でちょっとオーバーして使った場合とかは経験あるけど。
まぁそういうのはツール使えば発見できるんだけど、それじゃぁ本末転倒だし。
0083トリッキーの１
NGNGそうじゃなくて、そんなdefineをすると、
APIじゃない部分でコンパイルが出来なくなるよ、ということ。
完全MFC or 完全APIで書かれていたら問題はないけれど、
両者が混在している場合も十分考えられるでしょ？
もれなくラッパ出来るならば一番いいんだけれど、
多分API自身をラッパする以外の方法では無理だと思われます。
008431
NGNGなるほどねー
まぁチェックルーチンを後付けだとうまく行かない部分もあるかも。
理想的には開発時にチェックルーチン付けちゃえば問題ないんだけど。
0085トリッキーの１
NGNG所有権付きのスマートポインタもどきでハンドルクラスを実装すると
結構うまく行くんじゃないのかな？
その場合の所有権は、DCに対応する感じで。
誰か既に作ってそうだけれど、ご存じの方は？
0086デフォルトの名無しさん
NGNG0087デフォルトの名無しさん
NGNGすでにチェックを行うためじゃなくてそれで管理行っちゃった方がよいと思うが
0088デフォルトの名無しさん
NGNG0089デフォルトの名無しさん
NGNG0090デフォルトの名無しさん
NGNGいまさらで悪いんですが、C#ならリソースリーク防げるってのは、
VCLを使えばリーク防げる／VBを使えばリソース管理を気にする必要がない、
と言うのと同様の問題を含んでません？
APIを使うって事は、要はその開発環境の標準ライブラリだけじゃ実装しきれ
ない状況に追い込まれて仕方がなく使用するわけだから、C#になっても、結局
は（ポインタ使用可能なモードにしての）ポインタの管理、或いはそれに準ず
る問題に行きつく気がするんですけど。
0091デフォルトの名無しさん
NGNG実際ソノトオリ行けるかどうかは別として一般論に過ぎないが、
JNIやポインタ使用可能モードなC#やrubyの拡張ライブラリ(藁)みたいなものが
うまくいくかどうか？は、それらのクラスライブラリが拡張ライブラリに対して、
いかにハマリ「にくい」モデル(Frameworkといってもいい)を提供してくれてるか？に
かかっている、という面が有るように思える。
標準ライブラリが無ければ常に丸裸だ、というほどまでに
プログラミングの世の中は冷たくもなければAllOrNothingでもない。
というか、そんなつかえねぇ環境は滅びやがれってかんじ。
フレームワークっていう考え方が重要だよ。
ライブラリといわば逆の考え方。
ライブラリは他人が作ったサブを自分が作ったメインが呼ぶ。
フレームワークは自分が作ったサブを他人が作ったメインが呼ぶ。
0092デフォルトの名無しさん
NGNGAPIで欲しいリソースをVCLから貰うという方法でリークはだいぶ防げる筈
0093デフォルトの名無しさん
NGNG0094デフォルトの名無しさん
01/08/26 21:36ID:SM0Vd3m6■ このスレッドは過去ログ倉庫に格納されています