x86のLinux上SIGBUSはまれですが、コールスタックはしばしば混乱して、表示され、プラス信号システムプラットフォーム間の差が大きいほど、問題は、さらに困難は、整理のx86 Linuxについてここで少しを要約しますどのような状況は、バスエラーをトリガします。
マッピングファイルアクセス例外
これは、一般的に、プロセスの根本原因は、ファイルをmmapされ、別のプロセスは、この文書には、mmapの中でファイルを越えて、いくつかのメモリ・ページをその結果、カットオフユーザーモードのシナリオで最も一般的なSIGBUS、最も可能性の高いトリガーです：これらのページはSIGBUSの引き金となります超えてメモリアクセスの実際のサイズは、具体的には、次のシナリオである
プロセスがファイルをのmmapした後、他のプロセスがファイルを小さく切り捨てる、1。
2、動的データベースの更新、直接CPカバレッジ。
図3は、実行可能ファイルは、CPダイレクトカバレッジを更新しています。
システムは、効率は、多くの場合、対応するファイルのページが（切り捨て）が存在しない場合は、唯一、すぐに問題ではないかもしれないので、ファイルマッピングした後、書き込み機構にコピーを使用するために、ディスクファイルは、メモリにマップされたページでは通常、読み込み訪問するときに、特定のタイムラグがあるので、間違いを犯すだろう。
アンアラインドメモリアクセス
X86プラットフォーム上で整列されていないメモリにアクセスする場合、デフォルトでは問題になることはありませんが、ユーザーが手動でEFLAGSを設定することができますCPUは、非整列メモリアクセスに設定されている非整列メモリアクセスが発生した場合、この時点で許可されていない、SIGBUSは、スロー基準の具体例としては、[3]。
スタックフォールト例外
このシナリオインテル・デベロッパ・ファイルを観点から、通常、OSやメモリのハードウェアの問題は非常に稀であり、この異常はトラップではなく、私たちは多くの場合、ユーザーモード例外と言う何かに属し、この異常の3つの原因がある[4]：
1 、カノニカルアドレス違反。
カノニカルアドレスは、64ビットモード、64が全て0又は1ない対処する高いアドレス48を指します。
カーネル・スタック・ポインタによってアクセス非正規のアドレスは、RBPまたはRSPスタック障害トラップを送信する場合は、次のサンプルコード：
唯一のスタックポインタ操作がSIGBUSすることに注意してください、非スタック・ポインタは、そのような例外は唯一SIGSEGがスローされます引き起こしました。
図2に示すように、スタックポインタ操作参照アドレスは、スタックサイズの外側にあります。
私は、操作方法のこのタイプを再現しますが、文書をトリガすることができると述べていませんよ。
図3に示すように、スタック操作参照スタックセグメントが存在しません。
このような操作は、一般的に、カーネルやコンパイラのバグです。
要約すると、スタック障害は通常、ユーザーが最も可能性の高いカーネルやハードウェアの問題は、異常のmmap-関連していない場合は、状態をトリガーすることはほとんどありません、RSP / RBPに、このスタックポインタ操作に関連する必要があります（ここではいくつかの絶対的）、そのような例外は、通常、VAR / log / messagesに/でメッセージを出力し、次のコアになり：
引用文
[1] https://stackoverflow.com/questions/2089167/debugging-sigbus-on-x86-linux
[2] http://orchistro.tistory.com/206
[3] https://sourceware.org/bugzilla /show_bug.cgi?id=11357
[4] https://software.intel.com/sites/default/files/managed/39/c5/325462-sdm-vol-1-2abcd-3abcd.pdf