Escreva o código mais curto que gera uma falha de segmentação (SIGSEGV) em qualquer linguagem de programação.
Respostas:
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.
0. staticvariáveis começam como 0, e main;são static, como eu a declarei fora da função. c-faq.com/decl/initval.html
mainint, está localizado .bss, geralmente as funções estão localizadas .text, quando o kernel carrega o programa elf, cria uma página executável para .texte não -executable for .bss, assim, chamando main, você pula para uma página não executável e a execução de algo nessa página é uma falha de proteção.
main __attribute__((section(".text#")))=0xc3;FTFY (pelo menos, parece retornar sem bater no meu x86).
const main=195;,. Por mais interessante que esteja funcionando, o objetivo desse desafio do código de golfe era fazer com que o código fosse padrão, não funcionasse :).
kill -11 $$
RET
Este código segfaults.
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.
Segmentation fault: 11no Mac
Segmentation fault (core dumped)no Linux
\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.
OBTW
Não funciona online, apenas no intérprete C.
>>> import ctypes;ctypes.string_at(0)
Segmentation fault
Fonte: http://bugs.python.org/issue1215#msg143236
>>> 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 ...
main(){raise(11);}
int func(). ou seja, uma função retornando int, obtendo parâmetros não especificados. Nesse caso, raiseé uma função retornando int, usando um argumento int, portanto isso funciona (mesmo se o compilador reclamar).
/(?{??})/
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.
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).
<.
Sim, isso depende da implementação. SIGSEGV é o resultado provável de um bom compilador.
<deve ter efeito ou envolver-se.
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.
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
mainé uma variável int global inicializada com zero, então o que obtemos é o resultado da tentativa de executar alguns bytes zero. No x86, seria algo como add %al,(%rax)uma instrução perfeitamente válida que tenta alcançar a memória no endereço armazenado %rax. As chances de ter um bom endereço são mínimas.
[dx0]dx
causa um estouro de pilha
[dx0]armazena dx0na pilha, dduplica o elemento superior da pilha, xexibe o elemento superior da pilha ( dx0) e o executa. O que duplica o elemento da pilha superior e começa a executá-lo ... 0precisa estar lá para evitar que isso seja uma chamada final, para que todos eles se acumulem.
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.
1x8?
"11111111".
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.
it coerces 0 (stored as the immediate value 1)- por que 0 é armazenado como 1?
Obj.magic()0é um caractere curto :)
Golfe
. $0Inclua 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)⌠[]+⌡9!*.
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.
System.Runtime.InteropServices.Marshal.ReadInt32(IntPtr.Zero);
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.
int i=*(int*)0;retorna uma NullReferenceException para mim.
*(int*)-1=0e obter uma violação de acesso.
*(int*)0=0lança uma exceção é provavelmente devido à otimização. Especificamente, para evitar o custo da verificação null, o otimizador pode remover verificações nulas, mas quando ocorre um segfault, ele pode ser repetido novamente como apropriado NullReferenceException.
$ 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.
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
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.
(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.
Em resposta a uma pergunta minha, Amro apresentou essa peculiaridade:
S = struct();
S = setfield(S, {}, 'g', {}, 0)
clear()
Limpa absolutamente tudo, não apenas o escopo atual, que obviamente causa muitos problemas, que resultam em JS explodindo e segfaulting
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.
jem 1e 0, que tenta converter 1na base 0. Por que segfaults, eu não tenho idéia ...