3
ArcObjectsのIFeatureClass.Search（直接接続を使用するSDEのみ）のメモリリークに対処しますか？
ESRIサポートは、問題を再現し、バグレポート（NIM070156）を開いたと言います。 .NET / C＃ArcMapアドインのツールが空間クエリ（クエリフィルターでICursorfrom IFeatureClass.Searchを返す）を実行するときに発生するメモリリーク（アンマネージヒープメモリ）があると判断しましたISpatialFilter。すべてのCOMオブジェクトは、必要がなくなるとすぐに解放されます（を使用Marshal.FinalReleaseCOMObject）。 これを判断するには、まず、ArcMap.exeのプライベートバイト、仮想バイト、ワーキングセットのカウンターを使用してPerfMonセッションを設定し、クエリを実行するツールを使用するたびに3つすべてが着実に増加（反復ごとに約500 KB）することに注意しました。重要なのは、直接接続（ST_Geometryストレージ、Oracle 11gクライアントおよびサーバー）を使用してSDEのフィーチャクラスに対して実行された場合のみです。ファイルジオデータベースを使用する場合、およびアプリケーション接続を使用する古いSDEインスタンスに接続する場合、カウンターは一定のままでした。 その後、LeakDiagとLDGrapherを使用し（このブログ投稿からのいくつかのガイダンスを使用）、Windowsヒープアロケーターを3回ログに記録しました。さらに数十回。 LDGrapherのデフォルトビュー（合計サイズ）に表示される結果は次のとおりです。 赤い線の呼び出し履歴は次のとおりです。 ご覧のとおりSgsShapeFindRelation2、sg.dll の関数がメモリリークの原因となっているようです。 私が理解しているように、sg.dllはArcObjectsで使用されるコアジオメトリライブラリSgsShapeFindRelation2であり、おそらく空間フィルターが適用される場所です。 他のことをする前に、他の誰かがこの問題（または同様の問題）に遭遇したかどうか、そしてそれについて何ができるかを確認したかっただけです。また、直接接続でのみこれが発生する理由は何ですか？これは、ArcObjectsのバグ、構成の問題、またはプログラミングの問題のように聞こえますか？ この動作を生成するメソッドの最小動作バージョンは次のとおりです。 private string GetValueAtPoint(IPoint pPoint, IFeatureClass pFeatureClass, string pFieldName) { string results = ""; ISpatialFilter pSpatialFilter = null; ICursor pCursor = null; IRow pRow = null; try { pSpatialFilter = new SpatialFilterClass(); pSpatialFilter.Geometry = pPoint; …