回答:
main;
これは変数宣言です- intタイプは暗黙的で（B言語からコピーされた機能）、0デフォルト値です。実行されると、これは数字を実行しようとし（数字は実行不可能です）、を引き起こしSIGSEGVます。
main、それが中に位置して、intで.bss、通常の機能は次の場所にあります。.textカーネルはエルフのプログラムをロードするとき、それはのために実行可能なページを作成.textし、非-executable for .bssので、mainを呼び出すと、実行不可能なページにジャンプし、そのようなページで何かを実行すると保護違反になります。
main __attribute__((section(".text#")))=0xc3;FTFY（少なくとも、x86ではクラッシュせずに戻るようです）。
const main=195;。興味深いのは、それが機能していることです。このコードゴルフの課題の目標は、コードがセグメンテーション違反になることでした。
kill -11 $$
RET
このコードはセグメンテーション違反です。
exec'()'*7**6
Windowsは、セグメンテーションフォールトのサブタイプであると想定するc00000fd（スタックオーバーフロー）のエラーコードを報告します。
Alex A.とMegoのおかげで、MacおよびLinuxシステムでもセグメンテーションエラーが発生することが確認されています。Pythonは、移植性のあるプログラムのクラッシュに最適な言語です。
Segmentation fault: 11Macの場合
Segmentation fault (core dumped)Linux上で
\def~#1{\meaning}\write0{\expandafter~\string}\bye
これは実際にはおそらくバグですが、Knuthによって書かれた元のTeX tex filename.texにはpdftex filename.tex存在しません。
>>> import ctypes;ctypes.string_at(0)
Segmentation fault
ソース：http : //bugs.python.org/issue1215#msg143236
>>> import sys;sys.setrecursionlimit(1<<30);f=lambda f:f(f);f(f)
Segmentation fault
ソース：http : //svn.python.org/view/python/trunk/Lib/test/crashers/recursive_call.py?view=markup
これは私がテストしているPythonバージョンです。
Python 2.6.1 (r261:67515, Jun 24 2010, 21:47:49)
[GCC 4.2.1 (Apple Inc. build 5646)] on darwin
一般に、Pythonインタープリターはクラッシュしにくいですが、上記は選択的虐待です...
main(){raise(11);}
int func()。つまり、int指定されていないパラメーターをとる関数を返します。この場合raiseは、intを引数に取るintを返す関数であるため、これは機能します（コンパイラが文句を言っても）。
/(?{??})/
5.14では、正規表現エンジンは再入可能になったため、この方法でクラッシュすることはありませんでしたが、これを試してみると5.12以前はセグメンテーション違反になります。
<.
はい、これは実装依存です。SIGSEGVは、優れたコンパイラの結果である可能性があります。
<は効果がないか、ラップアラウンドする必要があります。
Cバージョンは次のとおりです。
*(int*)0=0;
プログラム全体（ISOに完全には準拠していません。K＆R Cと仮定しましょう）は19文字です。
main(){*(int*)0=0;}
アセンブラーバリアント：
orl $0,0
プログラム全体の長さは24文字です（実際にはアセンブラーではないため、評価用です）。
main(){asm("orl $0,0");}
編集：
いくつかのCバリアント。最初のものは、グローバルポインター変数のゼロ初期化を使用します。
*p;main(){*p=0;}
2番目は無限再帰を使用します：
main(){main();}
最後のバリアントは最短の 1-7（15）文字です。
編集2：
上記のいずれかより短いもう1つのバリアントを考案しました-6（14）文字。リテラル文字列は読み取り専用セグメントに入れられると想定しています。
main(){*""=0;}
編集3：
そして最後の試み-1文字の長さ：
P
次のようにコンパイルします。
cc -o segv -DP="main(){main();}" segv.c
main、ゼロで初期化されたグローバルint変数であるため、ゼロバイトを実行しようとした結果が得られます。x86ではadd %al,(%rax)、に格納されて%raxいるアドレスのメモリに到達しようとする完全に有効な命令であるようなものになります。良い住所を持っている可能性は最小限です。
[dx0]dx
スタックオーバーフローを引き起こす
[dx0]dx0スタックに保存してからd、一番上のスタック要素を複製し、一番上のスタック要素をxポップ（dx0）して実行します。これは、一番上のスタック要素を複製し、それを実行し始めます... 0これが末尾呼び出しであるのを防ぐためにそこにいる必要があるので、それらはすべて積み上げられます。
ややチートな解決策は、Joey Adamsのbashトリックから1文字を剃ることです。
kill 11,$$
ただし、Perlで実際のセグメンテーション違反を取得するにunpack pは、明らかな解決策があります。
unpack p,1x8
技術的には、アドレス0x31313131（または64ビットシステムでは0x3131313131313131）が偶然有効なアドレス空間を指しているだけなので、セグメンテーション違反は保証されません。しかし、反対は反対です。また、perlがポインターが64ビットより長いプラットフォームに移植された場合、これx8を増やす必要があります。
1x8ですか？
"11111111".
ゴルフ
. $0スクリプトを再帰的に自分自身に含めます。
説明した
再帰的な「ソース」（。）の操作は、最終的には、スタックオーバーフローを引き起こし、とバッシュはと統合されていませんlibsigsegv、これはSIGSEGVになります。
ここで説明したように、これはバグではなく、予想される動作です。
テスト
./bang
Segmentation fault (core dumped)⌠[]+⌡9!*.
上記がクラッシュしない場合、数値を増やしてみてください（複数桁の数値は、実際には先頭にコロンを付けて指定します）
深くネストされたオブジェクトを含むpythonのバグを悪用してインタープリターをクラッシュさせitertools.chainます。これは実際に+演算子の実装に使用されます。
System.Runtime.InteropServices.Marshal.ReadInt32(IntPtr.Zero);
unsafe{int i=*(int*)0;}
これが機能するには、/ unsafeでコンパイルする必要があります。何らかの理由で私は理解できませんが、*(int*)0=0このバージョンでは適切なアクセス違反が発生しますが、NullReferenceExceptionをスローするだけです。
int i=*(int*)0;私のためのリターンとNullReferenceException。
*(int*)-1=0、アクセス違反を取得することができます。
*(int*)0=0例外をスローする理由は、おそらく最適化が原因です。具体的には、のチェックのコストを回避するためnullに、オプティマイザーはnullチェックを削除できますが、セグメンテーション違反が発生した場合、適切なものとして再スローできますNullReferenceException。
real,pointer::p(:)=>null()
p(1)=0.
end
コンパイル：
gfortran segv.f90 -o segv
実行：
./segv
Program received signal SIGSEGV: Segmentation fault - invalid memory reference.
Backtrace for this error:
#0 0x7FF85FCAE777
#1 0x7FF85FCAED7E
#2 0x7FF85F906D3F
#3 0x40068F in MAIN__ at segv.f90:?
Erreur de segmentation (core dumped)
材料：
gfortran --version
GNU Fortran (Ubuntu 4.8.4-2ubuntu1~14.04.1) 4.8.4
main(a){*(&a-1)=1;}
main関数の戻りアドレス値が破損しているため、の戻り時にSIGSEGVを取得しmainます。
（これは私にとってテーマになりつつあります。おそらく、それがここで他の誰もしていないことを知っている唯一の言語だからです。）
inc(r0)
プログラムの開始時点で、r0（simhデバッガーによれば05162である）の初期値でアドレス指定された単一バイトをインクリメントします。
0000000 000407 000002 000000 000000 000000 000000 000000 000000
0000020 005210 000000
そして、いつものように、最後の余分なバイトはstripで削除できます。
ソースを短くするためにいくつかの試みをしましたが、常に構文エラーまたはSIGBUSのいずれかを取得することになりました。
clear()
現在のスコープだけでなく、明らかに多くのブロックを引き起こし、JSが爆発し、セグメンテーション違反に陥るだけでなく、絶対にすべてをクリアします。
j1Z
これは、私が合法的に何の手がかりも持っていないことを除いて、私がこの答えを思いついた方法を説明する部分です。誰かがこれを説明してくれたら、ありがたいです。
説明
jは、ベースを二乗し、ベースが少なくとも数値と同じになるまで再帰的に呼び出します。基数は0なので、それは決して起こりません。十分に高い再帰制限により、セグメンテーション違反が発生します。
jていることがわかりました。なぜセグメンテーションフォールトが、私は考え...持っていないこと1010