問題タブ [debugbreak]

Xcodeでハードブレークを引き起こす命令は何ですか? たとえば、Visual Studio では、'_asm int 3' または 'DebugBreak()' を実行できます。一部の GCC 実装では、asm("break 0") または asm("trap") です。

Xcodeでさまざまなコンボを試しましたが、運がありませんでした。(インライン アセンブラは正常に動作するため、構文の問題ではありません)。

参考までに、これは assert マクロ用です。移植性と、XCode が提供するバージョンで abort() を実行するように見えるため、assert.h の定義を使用したくありません。

ジョン - スーパー、乾杯。参考までに、int 3 構文は、Intel Mac および iPhone に必要なものです。

Chris - コメントありがとうございます。しかし、さまざまなプラットフォームに移植されたコードベースに対して標準の assert() 関数を避けるべき多くの理由があります。独自の assert をローリングするのに苦労した場合、それは通常、保持したい追加機能 (ログ、スタックの巻き戻し、ユーザー操作) があるためです。

「__assert」などの実装を介してハンドラーを置き換えようとする提案は移植性がありません。標準の「assert」は通常マクロであり、Mac では __assert にマップされる場合がありますが、他のプラットフォームではマップされません。 .

構文は何ですか? また、どの名前空間/クラスをインポートする必要がありますか? 可能であればサンプルコードを教えてください。それは大いに役立つでしょう。

Visual Studio を使用してネイティブ アプリケーションを開発しています。コードに __asm int 3 または __debugbreak を使用して配置されたプログラム ブレークポイント (アサート) があります。ヒットしたときに、同じデバッグセッションでの連続したヒットがデバッガーに侵入しないように、それを無効にしたい場合があります。これどうやってするの？

MSVC では、DebugBreak()または__debugbreakによってデバッガーが中断されます。x86 では "_asm int 3" を書くのと同じですが、x64 では何か違います。gcc (またはその他の標準コンパイラ) でコンパイルするときは、デバッガーも中断したいと考えています。プラットフォームに依存しない関数または組み込み関数はありますか? それについてのXCode の質問を見ましたが、移植性が十分ではないようです。

サイドノート: 私は主にそれで ASSERT を実装したいと思っています。そのために assert() を使用できることは理解していますが、DEBUG_BREAK などをコードに書きたいと思っています。

つまり、コードに有用なアサーションを含めるにはどうすればよいでしょうか?

MFC は非常に簡単です。ASSERT(何か)を使用するだけです。

非 MFC の方法は何ですか?

編集: assert() を呼び出したファイルではなく、assert.c でアサートの破損を停止することは可能ですか?

編集:<assert.h> &の違いは何<cassert>ですか?

受け入れられた回答:この投稿には素晴らしい回答がたくさんあります。複数の回答を受け入れることができたらいいのにと思います (または、誰かがそれらすべてを組み合わせてくれるでしょう)。したがって、回答はフェルッチョに授与されます（最初の回答に対して）。

デバッグ時には、デバッガーでアプリケーションを起動するだけでなく、すでに実行中のプロセスをアタッチする必要がある場合があります。

デバッガーを簡単に接続できるように、Sleep（）またはMessageBox呼び出しを行うのが一般的です。これらのいくつかが最終的にソース管理にコミットされるのではないかと心配しています。

実行中のプロセスにデバッガーを接続できるように十分な時間を遅らせながら、この状況を回避するための最善の方法は何ですか？

スリープまたはメッセージボックスをで保護すること#ifdef _DEBUGは1つの方法ですが、もっと良い方法があるかどうか疑問に思っています。

スリープを使用すると、時間内にアタッチできない可能性があるという問題もあります。MessageBoxを使用すると、リモートでデバッグしている、またはGUIが表示されていないプロセスをデバッグしている可能性があるという問題があります（Vistaでサービスとして実行されている例）。

私は次の記事を見つけました：

http://software.intel.com/en-us/articles/intel-fortran-compiler-microsoft-debugging-function-debugbreak/

残念ながら、このコードを実装してコンパイルしようとすると、次のエラーが発生しました。

エラー1エラー＃7286：このシンボルには、DEC $ATTRIBUTESALIAS属性が複数回宣言されています。[デバグブレイク]176

私はIntelFORTRANコンパイラーを使用しています。

追加の洞察は大歓迎です。

iPad用のDebugBreakを作成したいのですが、asm {trap}が機能するはずですが、問題があります。asm{trap}を使用すると、エラーが発生します。asmブロックが有効になっていない場合は、`-fasm-blocks'を使用してください。-fasm-blocksを有効にすると、別のエラーが発生します。-fasm-blocksオプションはARMではサポートされていません。

DebugBreakを実装する別の方法、またはiPadでasmコードをコンパイルする別の方法を知っていますか？

私のアプリケーションにはカスタムのクラッシュ処理が組み込まれています (「Windows アプリケーションのデバッグ」に関する John Robbins の優れた本を参照してください)。この機能をテストするために、私は常に Windows 関数 DebugBreak() を使用しましたが、これは常に完全に機能しました。しかし、Windows 7 以降、この関数を呼び出すと、「ブレークポイントに到達しました」と表示され、クラッシュ ハンドラを呼び出さずにアプリケーションが停止します。

クラッシュ機能をテストするために、いつでもこのコードをアプリケーションに入れることができます。

または、0xdeadbeef が有効なアドレスである場合に備えて、いくつかのケースを追加することもできます。

しかし、私は疑問に思っていました: Windows でアプリケーションをクラッシュさせるよりクリーンな方法はありませんか?

次の単純なソース（test.cppという名前）を使用します。

次のコマンドを使用して、これをコンパイルしてリンクします。

TEST.EXEが（64ビットのWindows 7システムで）実行されると、次のダイアログが表示されます。

次に、次のソースファイルを追加します（test2.cppという名前を付けます）。

そして、これをコンパイルして、次のように最初のソースとリンクします。

hello-functionを呼び出さず、リンクしただけであることに注意してください。

次に、TEST.EXEを再度実行します（同じ64ビットWindows 7システムで）。上記のダイアログの代わりに、次のように表示されます。

どうやら、.Net Frameworkでリンクすると、DebugBreakの動作が異なります。どうしてこれなの？そして、どうすれば古いDebugBreakの動作を元に戻すことができますか？これはおそらくWindows7または64ビット固有の動作ですか？

DebugBreakを使用する理由を明確にするための補足：カスタムassert-framework（JohnRobbinのDebuggingWindows ApplicationsブックのSuperAssertのようなもの）があり、開発者がデバッガーにジャンプできるようにDebugBreak関数を使用します（または、問題がある場合は、新しいデバッガーを開きます）。これで、単純なポップアップのみが表示され、デバッガーにジャンプすることはできなくなりました。

別の解決策として、ゼロ除算または無効なアドレスへの書き込みを実行することもできますが、これはあまりクリーンな解決策ではありません。

編集： これは2番目のテスト（単純なダイアログ）の呼び出しスタックです：

これは、最初のテストの呼び出しスタックです（「閉じる」と「デバッグ」を選択したダイアログ）。

違いはntdll.dll！Executehandler2@20から始まります。.net以外のアプリケーションでは、を呼び出しますntdll.dll!@_EH4_CallFilterFunc。.netアプリケーションでは呼び出しclr.dll!__except_handler4です。