「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などのデバッグブレークポイントを削除するのを忘れたことに気づきました。ただし、アプリは確実にアクティブなビルド構成として「リリース」を使用してビルドされました。 「Release」構成を使用すると、ブレークポイントの設定ができなくなると思いますが、それでもブレークポイントがどのように機能するか、ブレークポイントを有効にするためにプログラムをgdb内から実行する必要があるかどうかはわかりません。
私の質問は次のとおりです。ブレークポイントを設定したままにしておくことは、ユーザーが観察するクラッシュの原因になりますか？もしそうなら、なぜブレークポイントはこの一人のユーザーだけに問題を引き起こすのでしょうか？そうでない場合、[NSFont fontWithName：size：]で他の誰かが同様の問題を抱えていますか？
たぶん、ブレークポイントを削除してユーザーに送り返すだけですが、そのユーザーにどれだけの通貨が残っているのかわかりません。そして、ブレークポイントを設定したままにしておくと問題が発生する可能性があるかどうかをより一般的に理解したいと思います（「リリース」構成を使用してアプリをビルドする場合）。
「EXC_BREAKPOINT（SIGTRAP）」例外は、ブレークポイントのデバッグが原因ですか？
いいえ、実際には別の方法です。実際のブレークポイントと同じように、SIGTRAP（トレーストラップ）によってデバッガがプログラムを中断（割り込み）します。しかし、それはデバッガーがクラッシュ時に常に壊れ、SIGTRAP（他のいくつかの signals と同様）がクラッシュの一種であるためです。
SIGTRAPは通常、NSExceptionがスローされることで発生しますが、常にではありません。直接 raise oneを直接実行することも可能です。
_NSLockError、[NSException raise]、objc_exception_throwなどのデバッグブレークポイントを削除するのを忘れたことに気づきました。
これらはブレークポイントではありません。それらの2つは関数と-[NSException raise]はメソッドです。
これらの関数とそのメソッドにブレークポイントonを設定したのですか？
「リリース」構成を使用すると、ブレークポイントを設定できなくなると思います。
番号。
構成は、build構成です。 Xcodeがアプリケーションを構築する方法に影響します。
ブレークポイントはビルドの一部ではありません。デバッガで設定します。これらは、デバッガーでプログラムを実行するときにのみ存在し、ヒットするだけで、プログラムを停止するだけです。
これらはビルドの一部ではないため、単にアプリバンドルを提供するだけでは、ブレークポイントをユーザーに渡すことはできません。
ブレークポイントがどのように機能するか正確にはわかりません…
プログラムがブレークポイントに達すると、デバッガーがプログラムを中断（中断）します。プログラムの状態を調べ、慎重に前進して、プログラムがどのように失敗するかを確認できます。
プログラムを停止するのはデバッガーであるため、デバッガーでプログラムを実行していない場合、ブレークポイントは効果がありません。
…または、ブレークポイントを有効にするためにプログラムをgdb内から実行する必要があるかどうか。
します。デバッガーブレークポイントは、デバッガー内でのみ機能します。
私の質問は次のとおりです。ブレークポイントを設定したままにしておくことは、ユーザーが観察するクラッシュの原因になりますか？
番号。
まず、前述のように、これらのブレークポイントが何らかの形でユーザーのシステムに引き継がれたとしても、ブレークポイントはデバッガーでのみ有効です。プログラムがデバッガーの下で実行されていない場合、デバッガーはブレークポイントで停止できません。特にクラッシュログを取得したため、ユーザーはほとんど確実にデバッガーでアプリを実行していません。
これらのブレークポイントがすべて設定された状態でデバッガーでアプリを実行したとしても、プログラムがそのポイントに到達したときにのみブレークポイントがヒットするため、これらのブレークポイントの1つは_NSLockError、-[NSException raise]、 または objc_exception_throw。そのポイントに到達することは問題の原因ではなく、問題の症状です。
そして、それらの1つが呼び出された結果としてクラッシュした場合、クラッシュログには少なくとも1つの名前が付けられます。そうではありません。
したがって、これはブレークポイント（別のマシン、デバッガーが関与していない）とは関係がなく、Cocoa例外ではありませんでした-前述したように、Cocoa例外はSIGTRAPの原因の1つですが、それだけではありません。別の問題に遭遇しました。
そうでない場合、[NSFont fontWithName：size：]で他の誰かが同様の問題を抱えていますか？
クラッシュログを切り捨てたために、発生した問題が似ているかどうかを判断する方法はありません。クラッシュが発生したコンテキストについては何も知りません。
切り取るのが良いのは「バイナリイメージ」セクションだけです。これは、dSYMバンドルがないためです。つまり、そのセクションを使用してクラッシュログを記号化することはできません。
一方、あなたはできます。この目的で アプリ を書きました。クラッシュログをフィードすると、dSYMバンドルが自動的に検出され（配布するリリースビルドごとにdSYMバンドルが保持されますよね？）、関数とメソッドが表示されるすべての場所でスタックトレースに関数名とメソッド名が復元されます。
詳細については、 Xcode Debugging Guide を参照してください。
このユーザーには破損したフォントがインストールされている可能性が非常に高いです。スタックトレースは、1人のユーザーのみに影響しているという事実と同様に、この仮説を確実にサポートしています。
その場合、発生するクラッシュはAppleのコードの奥深くで発生するため、問題のあるフォントをユーザーに削除させる以外に、できることはあまりありません。
Font Bookでユーザーにフォント検証を実行してもらいます。これを行うには、Font Bookを起動し、ソースリストでAll Fontsをクリックしてから、リストされているすべてのフォントを選択します。次に、FileメニューからValidate Fontsを選択できます。
ブレークポイントはバイナリに書き込まれません。この人のOSのインストールが壊れているのは良いことです。コンソールログでdyldメッセージを確認してください。
同じエラーが発生しました。説明できない理由により、ブレークポイントはEXC_BREAKPOINT例外のスローの原因でした。解決策は、ブレークポイントを削除し、コードが機能するようにすることでした。
EXC_BREAKPOINTは、デバッガーが使用する例外の一種です。コードにブレークポイントを設定すると、コンパイラは実行可能コードにこのタイプの例外を挿入します。実行がそのポイントに達すると、例外がスローされ、デバッガーがキャッチします。次に、デバッガーは「ブレークポイントが設定された」行にコードを表示します。これがデバッガの仕組みです。ただし、この場合、デバッガーは例外を正しく処理せず、通常の例外エラーとして表示されます。
私は私の人生でこのエラーを2回発見しました。
- 1年ほど前にXcodeを使用している人。
- もう1つは、約15年前にVisual C++を使用しています。