シグナル11とは何を意味しますか？
シグナル11、正式には「セグメンテーションフォールト」と呼ばれ、プログラムが割り当てられていないメモリ領域にアクセスしたことを意味します。これは通常、プログラムのバグです。自分でプログラムを書いている場合は、これが最も可能性の高い原因です。しかし、このFAQではその他の可能性に焦点を当てます。
カーネルコンパイル中に以下のエラーが発生します：
gcc: 内部コンパイラエラー: プログラム cc1 が致命的なシグナル 11 を受け取りました
コンパイラには何か問題がありますか？どのバージョンのコンパイラが必要ですか？カーネルに何か問題がありますか？
おそらくインストール、コンパイラ、またはカーネルに問題はありません。ハードウェアに関連する可能性が高いです。いくつかのサブシステムが問題である可能性があり、いくつかの方法で修正できます。詳しくは以下をご覧ください。ただし、この「ルール」には2つの例外があります。仮想メモリが不足している場合や、Red Hat 5.x、6.x、7.xをインストールしている場合があります。これについては後ほど説明します。
ソフトウェアの問題ではないとしたら、どうすれば確実にわかりますか？
まず、ハードウェアが原因かどうか確認しましょう。「make」が停止したら、「make」を再度入力してください。もし数個のファイルをさらにコンパイルしてから停止する場合は、ハードウェアが原因である可能性があります。すぐに再び停止する場合（つまり、「xxxxに対して何も行うことはありません」というディレクトリをスキャンしてから正確に同じ場所でクラッシュする場合）、次のように試してください：
dd if=/dev/HARD_DISK of=/dev/null bs=1024k count=MEGS
HARD_DISKを「hda」に変更し、ハードディスクの名前（例：hdaまたはsda。または「df .」を使用）に置き換えます。MEGSをメインメモリのメガバイト数に変更します。これにより、ハードディスクの最初の数メガバイトが読み込まれ、次回実行時にCソースファイルとgccバイナリが再読込されます。その後「make」を再度実行してください。それでも同じ場所で停止する場合は、ソフトウェアの問題である可能性があります。他の可能性についての質問を見てください...「dd」コマンドなしでコンパイラが同じ場所で停止し続ける場合でも、「dd」を使用後に別の場所に移動する場合、ディスク→RAM転送の問題があると考えられます。
本当にハードウェアの問題ですか？
コンパイラがメモリ範囲外にアクセスした場合、動作するハードウェアではこれはプログラミングエラーです。これが「内部コンパイラエラー」と表示される理由です。しかし、ハードウェアがたまにビットを反転させる場合、gccは多くのポインタを使用しているため、範囲外のアドレスにアクセスしてしまう可能性があります（ランダムなアドレスは通常範囲外です）。現在、ほとんどの人が「シグナル11」の問題でこのページに誘導されています。自分でソフトウェアを開発中または十分にデバッグされていないソフトウェアを使用している場合、「シグナル11」（またはセグメンテーションフォールト）はプログラムに何か問題があるという非常に強い兆候です。他の誰もが正常に動作するプログラム（例えばLinuxカーネル）でクラッシュする場合、ハードウェアに問題がある兆候です。システム内のハードウェアドライバなどのソフトウェアコンポーネントが破損している場合、ハードウェア障害と非常に似た症状を引き起こす可能性があります。ただし、ドライバが故障するとカーネル内で深刻なトラブルが発生する可能性が高いです。
ハードウェアの問題だとしたら、具体的には何ですか？
ハードウェアの問題の場合、以下が考えられます：
RAMタイミングの問題ですか？BIOS設定を一ヶ月以上前にいじりましたが、それ以来たくさんのカーネルをコンパイルしましたが問題はありませんでした。RAMタイミングではありませんよね？
違います。RAMメーカーが60ns RAMと70ns RAMを作る専用機械を持っているとは思えません。テストを行い、基準を満たすものを60nsとしています。温度が上昇するとチップは遅くなるため、夏の到来や長時間のコンパイルジョブが原因でコンピュータ内の温度が限界を超えることがあります。
ECCメモリを買わなかったことが悔やまれます。少し安いからです。ECCメモリを買うべきだったのですか？
より高価なECCメモリとマザーボードを購入することで、ランダムに通過するアルファ粒子によるエラーから保護されます。しかし、ほとんどの人が「gcc」を使って30分以内に「シグナル11」の問題を再現できる一方、メモリテストでは数時間かけても再現できない場合、これは単なるランダムなアルファ粒子によるビットの反転ではないと考えられます。CPU、キャッシュ、メモリパスでのタイミングエラーが主な原因と考えられます。ECCメモリはこの場合役立ちません。
メモリの問題ですか？BIOSのメモリテストではOKと表示されます。DOSの高度なメモリテストツールでも問題がないと表示されます。メモリの問題ではないですよね？
違います。BIOSのメモリテストは全く役に立ちません。時には実際に利用可能なメモリよりも多いメモリを「OK」と判定することもあります。
カーネルをコンパイルする時だけ発生しますか？
いいえ、ハードウェアがカーネルをコンパイルしていることを知る方法はありません。ただ、カーネルコンパイルはハードウェアに非常に厳しい負荷をかけるため、頻繁に発生します。他の大きなパッケージ（例えばgccやglibc）をコンパイルするときにも同様の問題が発生することがあります。
常にシグナル11ですか？
いいえ、シグナル4、6、7なども時々発生しますが、シグナル11が最も一般的です。メモリが破損している間は何でも起こり得ますが、gccがシグナル11を受信する可能性が最も高いです。
NT、Windows 95、98、ミレニアム、XPでは問題が発生しません。Linux特有の問題でしょうか？
まず、LinuxはこれらのOSよりもハードウェアに厳しい負荷をかけます。また、一部のOS（特にMicrosoftのもの）は予測不可能な方法でクラッシュします。これらのOSは多少予測可能であり、Excelのようなアプリケーションが常に同じメモリアドレスにロードされる場合、ビットエラーが発生しても常にExcelが影響を受けます。そのため、単一のアプリケーションが失敗しているように見えます。
どうすれば解決できますか？
以下のことを試してください。これらはコンピュータを正しく動作させ、問題を特定するのに役立ちます。
RAMがテスト機器でOKと表示されました。RAMではないですよね？
違います。現在のRAMのエラーはRAMテスト機器では検出できないことが多いです。あなたのマザーボードがRAMを疑わしい方法でアクセスしている可能性があります。
他のハードウェアが原因の可能性は？
コンピュータ内のすべてのハードウェアが原因の可能性がありますが、簡単に確認できるものはまず確認すべきです。すべてのカードが正しくマザーボードに挿入されていることを確認してください。
なぜRed Hatのインストールが失敗しますか？
Red Hat 5.x、6.x、7.xのインストーラーは一部のマシンで問題があります。32Mしか使用しないようにしてインストールを試みてください。これは通常「mem=32m」というブートパラメータで可能です。
他の可能性は？
他者によると、以下の可能性があります：