web-dev-qa-db-ja.com

例外コード「EXC_I386_GPFLT」の意味は何ですか？

例外コードEXC_I386_GPFLTの意味は何ですか？

その意味は状況によって異なりますか？

その場合、例外タイプEXC_BAD_ACCESSと例外コードEXC_I386_GPFLTを参照しています。

このプログラムはXcode 5.0.1で開発され、BLASライブラリのcblas_zgemm()を処理します（まあ、それは問題ではないと思います...）

どうもありがとうございました！

c++cexc-bad-access
109
Lewen

EXC_I386_GPFLTは、確かに「一般保護違反」を参照しています。これは、「許可されていないことをした」というx86の方法です。通常、メモリの範囲外にアクセスすることを意味しませんが、コードが範囲外になり、何らかの保護違反を引き起こす方法で不正なコード/データが使用される可能性があります。

残念ながら、これ以上のコンテキストなしに問題が何であるかを正確に把握することは困難です。AMD64プログラマーズマニュアル、2005年のVol 2には27の原因が記載されていますもっと。

64ビットシステムの場合、もっともらしいシナリオは、コードが「非標準のポインター」を使用していることです。つまり、64ビットアドレスは、アドレスの上位16ビットが下位48ビットの先頭のすべてのコピー（つまり、アドレスの上位16ビットは、16ビットのすぐ下のビットに基づいて、すべて0またはすべて1でなければなりません）。この規則は、アーキテクチャが「アドレス範囲の有効ビット数を安全に拡張できる」ことを保証するために設けられています。これは、コードがポインターデータを他のもので上書きするか、ポインター値を読み取るときに範囲外になることを示します。

別の可能性のある原因は、SSEレジスタを使用したアラインされていないアクセスです。つまり、16バイトのアラインされていないアドレスから16バイトのSSEレジスタを読み取ります。

私が言ったように、他にも多くの考えられる理由がありますが、それらのほとんどは、32ビットまたは64ビットOSでは「通常の」コードが実行しないことを含みます（無効なセレクタインデックスでセグメントレジスタをロードしたり、 MSR（モデル固有のレジスタ））。

100
Mats Petersson

多くの場合、ヘッダーファイルから情報を取得できます。例えば：

$ cd /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk
$ find usr -name \*.h -exec fgrep -l EXC_I386_GPFLT {} \;
usr/include/mach/i386/exception.h
^C
$ more usr/include/mach/i386/exception.h
....
#define EXC_I386_GPFLT          13      /* general protection fault     */

OK、それは一般的な保護違反です（とにかくその名前が示唆しているように）。グーグル「i386一般保護違反」は多くのヒットをもたらしますが、これは looks 興味深いです：

メモリ保護もセグメント記述子を使用して実装されます。まず、プロセッサは、セグメントレジスタにロードされた値が有効な記述子を参照しているかどうかをチェックします。次に、計算されたすべての線形アドレスが実際にセグメント内にあることを確認します。また、アクセスのタイプ（読み取り、書き込み、または実行）が、セグメント記述子の情報と照合されます。これらのチェックの1つが失敗すると、例外（割り込み）13（16進0D）が発生します。この例外は、一般保護違反（GPF）と呼ばれます。

その13はヘッダーファイルで見たものと一致するため、同じもののように見えます。ただし、アプリケーションプログラマの観点からは、参照すべきではないメモリを参照しているだけであり、ハードウェア上でどのように実装されているかは重要ではありません。

23
trojanfoe

ソースをデバッグして見つけるには、アプリのゾンビを有効にし（Product\Scheme）、Instrumentsを起動し、Zombiesを選択します。 Xcodeでアプリを実行してから、Instrumentsに進み、記録を開始します。アプリに戻り、エラーを生成してみてください。インストゥルメントは、（ゾンビへの）不正な呼び出しがあればそれを検出する必要があります。

それが役に立てば幸い！

21
Khalid Mammadov

私はユニットテスト中にこれがなぜ現れたのだろうと思いました。

throws;を含むプロトコルにメソッド宣言を追加しました。ただし、特定のテストでは潜在的にスローするメソッドは使用されませんでした。テストでゾンビを有効にすると、問題が多すぎるように思われました。

⌘Kcleanがトリックを行ったことが判明しました。それが実際の問題を解決するとき、私はいつも誇張しています。

16
ctietze

Swift 4.2でも同様の例外がありました。コードのバグを見つけようとして30分ほど費やしましたが、Xcodeを閉じて派生データフォルダーを削除すると、問題はなくなりました。ショートカットは次のとおりです。

rm -rf ~/Library/Developer/Xcode/DerivedData
4
Stanislau Baranouski

私の場合、iOSシミュレーターでアプリを実行すると、Xcodeでエラーがスローされました。 「エラーの意味」という特定の質問に答えることはできませんが、何が私を助けたのかを言うことはできます。

私にとっての解決策は、シミュレータではErase All Content and Settings、XcodeではClean Build Folder...でした。

2
Manuel

これを行っているときにこのエラーが発生しました：

 NSMutableDictionary *aDictionary=[[NSMutableDictionary alloc] initWithObjectsAndKeys:<#(nonnull id), ...#>, nil]; //with 17 objects and keys

私が戻ったとき、それは消えました：

NSMutableDictionary *aDictionary=[[NSMutableDictionary alloc] init];
[aDictionary setObject:object1 forKey:@"Key1"]; //17 times
0
Peter B. Kramer

selfをunownedとして定義するクロージャー内でエラーがスローされると、アクセスできるものが制限され、特定の状況でこのエラーコードを取得します。特にデバッグ中。この場合、[unowned self]を[weak self]に変更してみてください

0
Matjan

これは、Xcodeが2つの異なるクラスで同じ変数名を使用しているように見えなかったためです（変数名はどのプロトコルにも関連していませんが、同じプロトコルに準拠しています）。新しい変数の名前を変更しただけです。

デバッグ中に、クラッシュするセッターにアクセスして確認する必要がありました。この回答はiOSに適用されます

0
Stephen J