「EXC_BREAKPOINT（SIGTRAP）」の例外は、ブレークポイントのデバッグによって発生しますか？

私はすべてのテストマシンで非常に安定していて、ほぼすべてのユーザーに対して安定しているように見えるマルチスレッドアプリを持っています（クラッシュの苦情がないことに基づいています）。ただし、クラッシュレポートを送信してくれた1人のユーザーにとって、アプリは頻繁にクラッシュします。すべてのクラッシュレポート（最大10個の連続したレポート）は基本的に同じように見えます。

Date/Time:       2010-04-06 11:44:56.106 -0700
OS Version:      Mac OS X 10.6.3 (10D573)
Report Version:  6

Exception Type:  EXC_BREAKPOINT (SIGTRAP)
Exception Codes: 0x0000000000000002, 0x0000000000000000
Crashed Thread:  0  Dispatch queue: com.apple.main-thread

Thread 0 Crashed:  Dispatch queue: com.apple.main-thread
0   com.apple.CoreFoundation        0x90ab98d4 __CFBasicHashRehash + 3348
1   com.apple.CoreFoundation        0x90adf610 CFBasicHashRemoveValue + 1264
2   com.apple.CoreText              0x94e0069c TCFMutableSet::Intersect(__CFSet const*) const + 126
3   com.apple.CoreText              0x94dfe465 TDescriptorSource::CopyMandatoryMatchableRequest(__CFDictionary const*, __CFSet const*) + 115
4   com.apple.CoreText              0x94dfdda6 TDescriptorSource::CopyDescriptorsForRequest(__CFDictionary const*, __CFSet const*, long (*)(void const*, void const*, void*), void*, unsigned long) const + 40
5   com.apple.CoreText              0x94e00377 TDescriptor::CreateMatchingDescriptors(__CFSet const*, unsigned long) const + 135
6   com.apple.AppKit                0x961f5952 __NSFontFactoryWithName + 904
7   com.apple.AppKit                0x961f54f0 +[NSFont fontWithName:size:] + 39

（....詳細は次のとおりです）

まず、[NSFont fontWithName：size：]の調査に長い時間を費やしました。ユーザーのフォントがどういうわけか台無しになっているのではないかと思ったので、[NSFont fontWithName：size：]は存在しないものを要求していて、その理由で失敗していました。[[NSFontManager sharedFontManager] availableFontNamesWithTraits：NSItalicFontMask]を使用して一連のコードを追加し、フォントの可用性を事前に確認しました。残念ながら、これらの変更では問題は解決しませんでした。

_NSLockError、[NSException raise]、objc_exception_throwなどのデバッグブレークポイントを削除するのを忘れていることに気づきました。ただし、アプリは間違いなく「リリース」をアクティブなビルド構成として使用してビルドされました。「リリース」構成を使用すると、ブレークポイントの設定が妨げられると思いますが、ブレークポイントがどのように機能するか、またはブレークポイントを有効にするためにプログラムをgdb内から実行する必要があるかどうかはわかりません。

私の質問は次のとおりです。ブレークポイントを設定したままにしたことが、ユーザーが観察したクラッシュの原因である可能性がありますか？もしそうなら、なぜブレークポイントはこの1人のユーザーだけに問題を引き起こすのでしょうか？そうでない場合、他の誰かが[NSFont fontWithName：size：]で同様の問題を抱えていますか？

ブレークポイントを削除してユーザーに送り返すことを試みるかもしれませんが、そのユーザーにどれだけの通貨が残っているかわかりません。そして、ブレークポイントを設定したままにしておくと問題が発生する可能性があるかどうかをより一般的に理解したいと思います（アプリが「リリース」構成を使用して構築されている場合）。

「EXC_BREAKPOINT（SIGTRAP）」の例外は、ブレークポイントのデバッグによって発生しますか？

いいえ。逆に、実際には、SIGTRAP（トレーストラップ）を使用すると、実際のブレークポイントと同じように、デバッガーがプログラムを中断（中断）します。ただし、これは、デバッガーがクラッシュ時に常に中断し、SIGTRAP（他のいくつかのシグナルと同様）がクラッシュの一種であるためです。

SIGTRAPは通常、NSExceptionがスローされることによって発生しますが、常にではありません。自分で直接発生させることも可能です。

_NSLockError、[NSException raise]、objc_exception_throwなどのデバッグブレークポイントを削除するのを忘れていることに気づきました。

それらはブレークポイントではありません。そのうちの2つは関数で-[NSException raise]あり、メソッドです。

あなたはブレークポイントを設定もしかして上でそれらの機能とその方法？

「リリース」構成を使用すると、ブレークポイントの設定が妨げられると思います。

番号。

構成はビルド構成です。これらは、Xcodeがアプリケーションを構築する方法に影響を与えます。

ブレークポイントはビルドの一部ではありません。デバッガーで設定します。それらは存在するだけで、ヒットするだけで、デバッガーでプログラムを実行したときにのみプログラムを停止します。

これらはビルドの一部ではないため、アプリバンドルをユーザーに提供するだけではブレークポイントをユーザーに渡すことはできません。

ブレークポイントがどのように機能するのか正確にはわかりません…

プログラムがブレークポイントに達すると、デバッガーはプログラムを中断（中断）します。プログラムの状態を調べて、プログラムがどのように失敗するかを注意深く確認できます。

プログラムを停止するのはデバッガーであるため、デバッガーでプログラムを実行していない場合、ブレークポイントは効果がありません。

…または、ブレークポイントを有効にするためにプログラムをgdb内から実行する必要があるかどうか。

します。デバッガーブレークポイントは、デバッガー内でのみ機能します。

私の質問は次のとおりです。ブレークポイントを設定したままにしたことが、ユーザーが観察したクラッシュの原因である可能性がありますか？

番号。

まず、前述のように、これらのブレークポイントが何らかの形でユーザーのシステムに引き継がれたとしても、ブレークポイントはデバッガーでのみ有効です。プログラムがデバッガーで実行されていない場合、デバッガーはブレークポイントで停止できません。ユーザーはほぼ確実にデバッガーでアプリを実行していません。特に、クラッシュログアウトが発生したためです。

彼らはセットこれらのブレークポイントのすべてと、デバッガの下でアプリケーションを実行しなかった場合でも、ブレークポイントは、ときにのみ、あなたのプログラムに達するあなたやココアが呼び出された場合のポイントは、ので、これらのブレークポイントの一つが唯一の火をできることがヒットした_NSLockError、-[NSException raise]または、objc_exception_throw。その時点に到達することは問題の原因ではなく、問題の症状になります。

そして、それらの1つが呼び出された結果としてクラッシュした場合、クラッシュログには少なくとも1つの名前が付けられます。そうではありません。

したがって、これはブレークポイントとは関係がなく（別のマシン、デバッガーは関係ありません）、Cocoaの例外ではありませんでした。前述したように、Cocoaの例外はSIGTRAPの原因の1つですが、それだけではありません。あなたは別のものに遭遇しました。

そうでない場合、他の誰かが[NSFont fontWithName：size：]で同様の問題を抱えていますか？

クラッシュログを切り取ったため、発生した問題が類似しているかどうかを判断する方法はありません。クラッシュがどのような状況で発生したかについては何もわかりません。

dSYMバンドルがないため、切り取るのに適しているのは「バイナリイメージ」セクションだけです。つまり、このセクションを使用してクラッシュログを表すことはできません。

一方、あなたはできます。私はこの目的のためにアプリを書きました。クラッシュログをそれにフィードすると、dSYMバンドルが自動的に検出され（配布するリリースビルドごとにdSYMバンドルを保持しますよね？）、関数とメソッドが表示される場所でスタックトレースに関数とメソッドの名前を復元します。

詳細については、 『Xcode Debugging Guide』を参照してください。

このユーザーには破損したフォントがインストールされている可能性が非常に高いです。スタックトレースは、1人のユーザーにのみ影響するという事実と同様に、その仮説を確実にサポートします。

その場合、発生するクラッシュはAppleのコードの奥深くで発生するため、ユーザーに問題のあるフォントを削除してもらう以外にできることはほとんどありません。

FontBookでフォント検証を実行するようにユーザーに依頼してみてください。これを行うには、Font Bookを起動し、ソースリストの[すべてのフォント]をクリックして、リストされているすべてのフォントを選択します。次に、[ファイル]メニューから[フォントの検証]を選択できます。

ブレークポイントはバイナリに書き込まれません。この人が壊れたOSインストールを持っている可能性は高いです。コンソールログでdyldメッセージを確認してください。

同じエラーが発生しました。説明できない理由で、ブレークポイントがEXC_BREAKPOINT例外のスローの原因でした。解決策は、ブレークポイントを削除することでした。そうすれば、コードは機能します。

EXC_BREAKPOINTは、デバッガーが使用する例外の一種です。コードにブレークポイントを設定すると、コンパイラはこのタイプの例外を実行可能コードに挿入します。実行がそのポイントに達すると、例外がスローされ、デバッガーがそれをキャッチします。次に、デバッガーはコードを「ブレークポイント」行に表示します。これがデバッガーの仕組みです。ただし、この場合、デバッガーは例外を正しく処理せず、通常の例外エラーとして表示されます。

私は私の人生でこのエラーを2回見つけました：

• 1つは約1年前にXcodeを使用していました。
• もう1つは、約15年前にVisual C ++を使用していました。