Escreva o código mais curto que gera uma falha de segmentação (SIGSEGV) em qualquer linguagem de programação.

C, 5 caracteres

main;

É uma declaração variável - o inttipo está implícito (recurso copiado do idioma B) e 0é o valor padrão. Quando executado, isso tenta executar um número (os números não são executáveis) e as causas SIGSEGV.

Experimente online!

Bash, 11      

kill -11 $$

Assembly (Linux, x86-64), 1 byte

RET

Este código segfaults.

Python 2, 13

exec'()'*7**6

O Windows relata um código de erro de c00000fd (estouro de pilha), que eu suponho ser um subtipo de falha de segmentação.

Graças a Alex A. e Mego, também é confirmado que causa falhas de segmentação nos sistemas Mac e Linux. Python é a linguagem de escolha para travar seus programas de maneira portável.

pdfTeX (51)

\def~#1{\meaning}\write0{\expandafter~\string}\bye

Na verdade, isso provavelmente é um bug , mas não está presente no TeX original, escrito por Knuth: compilar o código em tex filename.texvez de pdftex filename.texnão produz um segfault.

LOLCODE, 4 bytes

OBTW

Não funciona online, apenas no intérprete C.

Python, 33 caracteres

>>> import ctypes;ctypes.string_at(0)
Segmentation fault

Fonte: http://bugs.python.org/issue1215#msg143236

Python, 60 caracteres

>>> import sys;sys.setrecursionlimit(1<<30);f=lambda f:f(f);f(f)
Segmentation fault

Fonte: http://svn.python.org/view/python/trunk/Lib/test/crashers/recursive_call.py?view=markup

Esta é a versão do Python em que estou testando:

Python 2.6.1 (r261:67515, Jun 24 2010, 21:47:49) 
[GCC 4.2.1 (Apple Inc. build 5646)] on darwin

Em geral, o intérprete Python é difícil de travar, mas o acima é abuso abusivo seletivo ...

Quarto - 3 caracteres

0 @

( @é uma busca)

C, 18

main(){raise(11);}

Perl (<5,14), 9 caracteres

/(?{??})/

Na 5.14, o mecanismo regex foi reentrado para que não pudesse ser travado dessa maneira, mas a versão 5.12 e anterior sofrerão um erro padrão se você tentar isso.

W32 .com executável - 0 bytes

Isso parecerá estranho, mas em sistemas Windows de 32 bits, criar e executar um arquivo .com vazio pode causar um segfault, dependendo de ... alguma coisa. O DOS simplesmente o aceita (o 8086 não possui gerenciamento de memória, não há segmentos significativos para falha) e o Windows de 64 bits se recusa a executá-lo (x86-64 não possui o modo v86 para executar um arquivo .com).

cérebro (2)

<.

Sim, isso depende da implementação. SIGSEGV é o resultado provável de um bom compilador.

Haskell, 31

foreign import ccall main::IO()

Isso produz um segfault quando compilado com o GHC e executado. Não são necessários sinalizadores de extensão, pois a Foreign Function Interface está no padrão Haskell 2010.

C - 11 (19) 7 (15) 6 (14) 1 caracteres, montador AT&T x86 - 8 (24) caracteres

A versão C é:

*(int*)0=0;

Todo o programa (que não é totalmente compatível com ISO, vamos assumir que é K&R C) tem 19 caracteres:

main(){*(int*)0=0;}

Variante do montador:

orl $0,0

O programa inteiro tem 24 caracteres (apenas para avaliação, já que não é realmente montador):

main(){asm("orl $0,0");}

EDIT :

Um par de variantes C. O primeiro usa a inicialização zero da variável global do ponteiro:

*p;main(){*p=0;}

O segundo usa recursão infinita:

main(){main();}

A última variante é a mais curta - 7 (15) caracteres.

EDIT 2 :

Inventou mais uma variante mais curta que qualquer uma das anteriores - 6 (14) caracteres. Ele pressupõe que cadeias literais são colocadas em um segmento somente leitura.

main(){*""=0;}

EDIT 3 :

E minha última tentativa - 1 caractere:

P

Basta compilar assim:

cc -o segv -DP="main(){main();}" segv.c

dc - 7 caracteres

[dx0]dx

causa um estouro de pilha

Perl, 10/12 caracteres

Uma solução levemente enganosa é raspar um char do truque de Joey Adams :

kill 11,$$

No entanto, para obter um segfault real no Perl, unpack pé a solução óbvia:

unpack p,1x8

Tecnicamente, isso não garante falha de segmentação, pois o endereço 0x31313131 (ou 0x313131313131313131 em sistemas de 64 bits) pode indicar um espaço de endereço válido por acaso. Mas as chances são contra. Além disso, se o perl for portado para plataformas em que os ponteiros tenham mais de 64 bits, x8será necessário aumentar.

Python 33

import os
os.kill(os.getpid(),11)

Enviando sinal 11 (SIGSEGV) em python.

OCaml, 13 bytes

Obj.magic 0 0

Isso usa a função Obj.magic, que coagora inseguramente quaisquer dois tipos. Nesse caso, ele coage 0 (armazenado como o valor imediato 1, devido ao bit de tag usado pelo GC) para um tipo de função (armazenado como um ponteiro). Assim, ele tenta desreferenciar o endereço 1 e, é claro, irá falhar.

Bash, 4 bytes

Golfe

. $0

Inclua recursivamente o script em si.

Explicado

A operação "origem" recursiva (.) Causa um estouro de pilha eventualmente e, como o Bash não se integra à libsigsegv , isso resulta em um SIGSEGV.

Observe que isso não é um bug, mas um comportamento esperado, conforme discutido aqui .

Teste

./bang 
Segmentation fault (core dumped)

Experimente Online!

Na verdade , 17 16 11 10 9 bytes

⌠[]+⌡9!*.

Experimente online!

Se o acima não falhar, tente aumentar o número (números de vários dígitos são especificados em Na verdade com dois pontos à frente)

Interrompe o interpretador explorando um bug em python envolvendo itertools.chainobjetos profundamente aninhados , que realmente são usados ​​para implementar o +operador.

C # - 62

System.Runtime.InteropServices.Marshal.ReadInt32(IntPtr.Zero);

Editar: 23

unsafe{int i=*(int*)0;}

Deve ser compilado com / inseguro para que este funcione. Por alguma razão que eu não entendo, *(int*)0=0apenas lança uma NullReferenceException, enquanto esta versão fornece a violação de acesso adequada.

PicoLisp - 4 caracteres

$ pil
: ('0)
Segmentation fault

Esse é o comportamento pretendido. Conforme descrito em seu site:

Se algumas linguagens de programação pretendem ser o "canivete suíço de programação", o PicoLisp pode muito bem ser chamado de "bisturi de programação": nítido, preciso, pequeno e leve, mas também perigoso na mão dos inexperientes.

F90 - 39 bytes

real,pointer::p(:)=>null()
p(1)=0.
end

Compilação:

gfortran segv.f90 -o segv 

Execução:

./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)

Materiais:

gfortran --version
GNU Fortran (Ubuntu 4.8.4-2ubuntu1~14.04.1) 4.8.4

19 caracteres em C

main(a){*(&a-1)=1;}

Ele corrompe o valor do endereço de retorno da função principal e obtém um SIGSEGV ao retornar main.

J (6)

memf 1

memfsignifica memória livre, 1é interpretada como um ponteiro.

Cython, 14

Isso geralmente é útil para fins de depuração.

a=(<int*>0)[0]

Montagem PDP-11 do Unix, binário de 18 bytes, fonte de 7 bytes

(isso está se tornando um tema para mim, talvez porque seja o único idioma que eu saiba que ninguém mais conhece).

inc(r0)

Incrementa o byte único endereçado pelo valor inicial de r0 [que passa a ser 05162 de acordo com o depurador simh] no início do programa.

0000000 000407 000002 000000 000000 000000 000000 000000 000000
0000020 005210 000000

E, como sempre, os bytes estranhos no final podem ser removidos com tira.

Fiz algumas tentativas para diminuir a fonte, mas sempre acabava recebendo um erro de sintaxe ou o SIGBUS.

Matlab - Sim, é possível!

Em resposta a uma pergunta minha, Amro apresentou essa peculiaridade:

S = struct();
S = setfield(S, {}, 'g', {}, 0)

Shell JavaScript, 7 bytes

clear()

Limpa absolutamente tudo, não apenas o escopo atual, que obviamente causa muitos problemas, que resultam em JS explodindo e segfaulting

Pitão, 3 caracteres

j1Z

Essa seria a parte em que eu explicaria como obtive essa resposta, exceto que eu legitimamente não tenho idéia . Se alguém pudesse explicar isso para mim, ficaria agradecido.

Aqui está um intérprete online.

Explicação

jesquadrinha a base e chama-se recursivamente até que a base seja pelo menos tão grande quanto o número. Como a base é 0 , isso nunca acontece. Com um limite de recursão suficientemente alto, você obtém um segfault.

- Dennis ♦