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

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

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

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

プログラムはXcode 5.0.1で開発されてcblas_zgemm()おり、BLASライブラリを扱います（まあ、それは問題ではないと思います...）

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

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

残念ながら、より多くのコンテキストなしで問題が何であるかを正確に理解するのは難しいかもしれません、私のAMD64プログラマーズマニュアル、2005年からの第2巻に27の異なる原因がリストされています。もっと。

64ビットシステムの場合、もっともらしいシナリオは、コードが「非標準ポインタ」を使用していることです。つまり、64ビットアドレスは、アドレスの上位16ビットが生成されないように形成されています。下位48ビットの上位のすべてのコピー（つまり、アドレスの上位16ビットは、16ビットのすぐ下のビットに基づいて、すべて0またはすべて1である必要があります）。このルールは、アーキテクチャが「アドレス範囲内の有効なビット数を安全に拡張」できることを保証するために設けられています。これは、コードが一部のポインターデータを他のもので上書きしているか、または一部のポインター値を読み取るときに境界を超えていることを示します。

別の原因として、SSEレジスタへの非境界整列アクセスが考えられます。つまり、16バイト境界で整列されていないアドレスから16バイトSSEレジスタを読み取ることです。

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

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

それが役に立てば幸い！

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

$ 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一般保護違反」をグーグルすると多くのヒットが発生しますが、これは興味深いように見えます。

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

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

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

以下を含むプロトコルにメソッド宣言を追加しましたthrows。しかし、潜在的にスローするメソッドは、その特定のテストでは使用されていませんでした。テストでゾンビを有効にするのは、面倒すぎるように思えました。

⌘Kクリーンがトリックをしたことがわかりました。それが実際の問題を解決するとき、私はいつも悩まされています。

Swift 4.2でも同様の例外がありました。コードのバグを探すのに30分ほど費やしましたが、Xcodeを閉じて派生データフォルダーを削除した後、問題は解決しました。これがショートカットです：

rm -rf ~/Library/Developer/Xcode/DerivedData

私の場合、iOSシミュレーターでアプリを実行すると、Xcodeでエラーがスローされました。「エラーの意味」という具体的な質問には答えられませんが、何が役に立ったかは言えますが、おそらく他の人にも役立つでしょう。

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

ビューを離れるときにこの問題が発生しました（前のビューに戻る）。

その理由は

addSubview(view)
view.translatesAutoresizingMaskIntoConstraints = false
NSLayoutConstraint.activate([
    view.leadingAnchor.constraint(equalTo: safeAreaLayoutGuide.leadingAnchor),
    view.topAnchor.constraint(equalTo: safeAreaLayoutGuide.topAnchor),
    view.trailingAnchor.constraint(equalTo: safeAreaLayoutGuide.trailingAnchor),
    view.bottomAnchor.constraint(equalTo: safeAreaLayoutGuide.bottomAnchor)
])

問題safeAreaLayoutGuideをself解決するために変更します。

意味は、ビューを安全領域ではなくスーパービューのリーディング、トレーリング、トップ、ボトムに揃えます）

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

デバッグしている間、それを見るためにクラッシュしていたセッターに足を踏み入れなければなりませんでした。この回答はiOSに適用されます

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

これを行っているときに私はこのエラーを受け取りました：

 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

私にとって、ストーリーボードに関連する問題は、以前はiOS 10.0以降に設定されていたセットiOS 9.0以降のViewControllerビルドのオプションです。実際には、verを10からiOS 9.3にダウングレードしたいと思っています。