Answers:
mainint，它位于中.bss，通常函数位于中.text，当内核加载elf程序时，它会为.textand 创建一个可执行页-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: 11在Mac上
Segmentation fault (core dumped)在Linux上
>>> 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。
<要么无效，要么环绕。
foreign import ccall main::IO()
使用GHC编译并运行时，这会产生段错误。不需要扩展标志，因为外部功能接口符合Haskell 2010标准。
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;}
第二个使用无限递归：
main(){main();}
最后一个变体是最短的一个 -7（15）个字符。
编辑2：
发明了一种比以上任何一种都短的变体-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技巧中删除一个char ：
kill 11,$$
但是，要在Perl中获得真正的段错误，unpack p是显而易见的解决方案：
unpack p,1x8
从技术上讲，这不能保证会发生段错误，因为地址0x31313131（或在64位系统上为0x3131313131313131）可能只是偶然指向有效的地址空间。但是，反对的可能性很大。另外，如果将perl移植到指针长于64位的平台，x8则需要增加。
1x8东西
"11111111".
Obj.magic 0 0
这使用函数Obj.magic，该函数不安全地强制使用任何两种类型。在这种情况下，它将强制0（由于GC使用的标记位而存储为立即数1）为函数类型（存储为指针）。因此，它尝试取消对地址1的引用，这当然会出现段错误。
it coerces 0 (stored as the immediate value 1)-为什么0被存储为1？
Obj.magic()0是一个短字符：)
打高尔夫球
. $0递归地将脚本包含到自身中。
讲解
递归的“源”（。）操作最终导致堆栈溢出，并且由于Bash不与libsigsegv集成，因此会产生SIGSEGV。
请注意，这是不是一个错误，但预期的行为，如讨论在这里。
测试
./bang
Segmentation fault (core dumped)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，优化器可以删除空检查，但是当发生段错误时，它可以适当地将其重新抛出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
clear()
清除所有内容，而不仅仅是清除当前范围，这显然会导致大量错误，从而导致JS崩溃和出现段错误
j1Z
这将是我解释如何得出此答案的部分，除非我完全不知道。如果有人能为我解释这一点，我将不胜感激。
说明
j将基数平方并递归调用自身，直到基数至少与数字一样大。由于基数为0，因此永远不会发生。具有足够高的递归限制，您会遇到段错误。
j在1and上执行0，并且试图转换1为base 0。为什么会发生段错误，我不知道...