頂点、標準、およびカラーバッファ（glBindBufferARB）の格納にVBO拡張を使用しています。 何らかの理由でバッファを変更したり、何らかの操作を行ったりすると、アプリケーションがアクセス違反でクラッシュします。デバッガを接続すると、nvidiaグラフィックスドライバに関連するdllで実行されたopengl呼び出しを実行するメインスレッドではないクラッシュがクラッシュすることがわかりました。VBO頂点バッファのデバッグ
おそらく、バッファーコールに不正なバッファーを指定したり、間違ったサイズを指定したことがあります。だから私の質問は、どのように私はこの状況をデバッグするのですか？クラッシュは、実際の呼び出しの後のある時間に、別のスレッドで発生するようです。
私はあなたがそのことを強引にしなければならないかもしれないと思います。 I.あなたのプログラムがもうクラッシュしなくなるまで、一度にいくつかの行を使ってvboをコメントアウトしてください。次に、どのラインを注目して、通過しているパラメータを本当に精査するかというアイデアが得られます。
また、glError（）コールをプログラムの周りに散りばめてみてください。多くの場合、偽のパラメータを渡すと、glErrorはクラッシュのポイントに達する前に、何かが間違っていると伝えます。
最高のOpenGl/D3Dデバッグツールの1つは、nVidiaのNvPerfHUDです。正確な問題を見つけるのに役立つわけではありませんが、レンダリングパイプラインに送信しているものを別の視点で表示します。
しかし、私はD3Dアプリケーションでしか使用していないと言えるので、OpenGLプログラムと同じくらい役立つかどうかはわかりません。
編集：
なぜこれが投票されたのか分かりません。私は前にNvPerfHUDでVBとIBの問題をデバッグしました。悪いプリミティブカウントなどの単純なもので、個々の描画コールを調べることで診断できます。
これはWindowsについてのもので、NVIDIAにはGLExpertツールがあります。さまざまなOpenGL警告/エラーを出力できます。
その他のケースでは、GLInterceptを使用してエラーチェックが有効なOpenGLコールインターセプタを使用すると便利です。
ツールが役に立たない場合は、よく古いデバッグです。問題を絞り込んで、クラッシュを引き起こす原因を突き止めてください。 NVIDIA固有の問題の場合は、別のドライバをインストールしてみるか、またはNVIDIA開発者フォーラムで質問してください。
NvPerfHUDは実際にはDirect3Dのみなので、OpenGLでは何の問題もありません。私はそれがあなたが投票された理由だと思います。 – Baxissimo
NvPerfHUDはこの質問/問題に関連するツールではありません。 –