SEGV_ACCERR の理由ですべてのシグナル SIGSEGV を持ついくつかのクラッシュを調べています。SEGV_ACCERR を検索した後、人間が読める説明に最も近いものを見つけました:オブジェクトの無効なアクセス許可
これは、より一般的な意味で何を意味するのでしょうか? SEGV_ACCERR はいつ発生しますか? この理由に関するより具体的なドキュメントはありますか?
SEGV_ACCERR の理由ですべてのシグナル SIGSEGV を持ついくつかのクラッシュを調べています。SEGV_ACCERR を検索した後、人間が読める説明に最も近いものを見つけました:オブジェクトの無効なアクセス許可
これは、より一般的な意味で何を意味するのでしょうか? SEGV_ACCERR はいつ発生しますか? この理由に関するより具体的なドキュメントはありますか?
これは主に 64 ビット iOS デバイスで見られるエラーで、複数のスレッドが ARC で変数を読み取って変更した場合に発生する可能性があります。たとえば、今日、複数のバックグラウンド スレッドが静的な NSDate および NSString 変数を読み取って使用し、ロックやキューイングを行わずにそれらを更新していたクラッシュを修正しました。
クラッシュ ログで何度も確認したように、複数のスレッドでコア データ オブジェクトを使用すると、このクラッシュが発生する可能性もあります。
私も Crittercism を使用していますが、この特定のクラッシュは SEGV_ACCERR であり、64 ビット デバイスにのみ影響を与えました。
コードが「テキスト」以外の場所から実行しようとする場合にこれを見てきました。
たとえば、ポインターがヒープまたはスタック内の関数を指していて、そのコードを (ヒープまたはスタックから) 実行しようとすると、CPU はこの例外をスローします。
スタック オーバーフローがSEGV_ACCERR
原因でを取得する可能性があります。具体的には、これは Android ARM64 で次のように発生しました。
VeryLargeStruct s;
s = {}; // SEGV_ACCERR
ゼロ初期化により一時的に作成され、スタック オーバーフローが発生したようです。-O0
これは;でのみ発生しました。おそらく一時的なものは、より高い最適化レベルで最適化されて取り除かれました。