Escreva um código perfeitamente legal em um idioma decente de sua escolha cuja compilação trava o compilador ou o envia para um loop infinito (tempo infinito de compilação).

Restrições:

• Use um idioma padrão usado no mundo real.
• Use um compilador padrão e bem desenvolvido (nenhuma resposta como "eu escrevi meu compilador C que trava em tudo").
• O código deve ser legal no idioma (portanto, você provavelmente terá que explorar um compilador ou um bug no idioma).
• Forneça a versão do compilador e as opções usadas para que outras pessoas possam replicá-lo.
• Explique por que o compilador travou, se possível.

Diverta-se :)

Tenho certeza de que foi corrigido agora, mas costumava ser possível travar o compilador Java (ou travar o Eclipse) escrevendo

class Foo {
  static double d = 2.2250738585072012e-308;
}

http://www.exploringbinary.com/java-hangs-when-converting-2-2250738585072012e-308/

Na verdade, de acordo com essa página, o compilador travará, não travará. Ainda assim, achei que foi bem divertido.

Minha solução favorita para o GHC:

data Bad a = C (Bad a -> a)

xx :: Bad a -> a
xx (x@(C x')) = x' x

omega :: a
omega = xx (C xx)

main = omega

Para GHC 6.12.1 ambos ghci Bad.hse ghc Bad.hslaço infinitamente. O GHC 7.4.1 faz loop infinitamente quando ghc -O2 Bad.hsé executado.

Explicação: omega é definida usando uma recursão infinita (a única maneira de ele habitar qualquer tipo). O inliner do compilador vê xxcomo uma função simples e não recursiva; portanto, tenta incorporá-lo na definição de omega. Isso resulta em (\x@(C x') -> x' x) (C xx). Vendo uma correspondência de padrões em um construtor, o compilador tenta reduzi-lo, obtendo xx (C xx)novamente e fazendo loops. O truque é que xxé realmente recursivo, mas a recursão está oculta no tipo de dados.

Nota: Ao escrever o quebra-cabeça, esqueci que deixei o GHC rodando no loop infinito. Levou toda a minha memória, travou o Firefox e eu mal consegui matá-lo sem reiniciar o hardware.

Isso é fácil em qualquer linguagem de tipo dependente . A verificação geral de tipos dependentes é indecidível, pois pode exigir cálculos arbitrariamente complexos (Turing-complete). Você pode simplesmente codificar em um tipo dependente um valor muito grande. Em seguida, o verificador de tipo usará toda a memória disponível e trava. Por exemplo, em Coq, ReyCharles dá o exemplo deCompute 70000. , o que faz com que o verificador de tipo construa um numeral Peano gigante e trate.

Em idiomas mais comuns que oferecem suporte a algum tipo de expansão macro ou metaprogramação, você pode fazer algo semelhante. Por exemplo, você pode usar toda a memória disponível em C:

#include <stdio.h>
#define a printf("%s", "Hello, world!\n");
#define b a a a a a a a a a a a a a a a a
#define c b b b b b b b b b b b b b b b b
#define d c c c c c c c c c c c c c c c c
#define e d d d d d d d d d d d d d d d d
#define f e e e e e e e e e e e e e e e e
// ...
#define z y y y y y y y y y y y y y y y y
int main() { z }

A linguagem de programação D permite a execução de funções em tempo de compilação . Isso pode ser usado para calcular algo em tempo de compilação muito grande para caber na memória. Algo semelhante pode ser alcançado usando a metaprogramação de modelos C ++.

Em XML (não uma linguagem de programação compilada, mas um processador XML é análogo a um compilador), as entidades em expansão podem fazer com que o processador fique sem memória:

<?xml version="1.0"?>
<!DOCTYPE lolz [
 <!ENTITY lol "lol">
 <!ENTITY lol1 "&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;">
 <!ENTITY lol2 "&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;">
 <!ENTITY lol3 "&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;">
...
]>
<lolz>&lol999;</lolz>

Isso é chamado de ataque de bilhões de risos .

C #

Encontrei isso em uma pergunta de stackoverflow :

using System;
using System.Linq;

public class Test
{
    public static void Main()
    {
        Enumerable.Range(0, 1).Sum(a =>
        Enumerable.Range(0, 1).Sum(b =>
        Enumerable.Range(0, 1).Sum(c =>
        Enumerable.Range(0, 1).Sum(d =>
        Enumerable.Range(0, 1).Sum(e =>
        Enumerable.Range(0, 1).Sum(f =>
        Enumerable.Range(0, 1).Count(g => true)))))));
    }
}

O compilador eventualmente irá falhar.

O problema parece relacionado à inferência de tipo e / ou geração lambda combinada com a resolução de sobrecarga.

VBA

Que tal se você pode travar o IDE digitando o código?

em qualquer aplicativo do Microsoft Office, tente o seguinte:

ALT+ F11para acessar a janela do VBA, tente o seguinte código

sub foo()
dim v(1 to 3, 1 to 3)
redim preserve v(,1 to 5)

e eis:

Você pode simplesmente digitar redim preserve v(,1 to 5)na janela imediata e ela falhará depois que você pressionar ENTER!

Perl (15)

BEGIN{1while 1}

Isso cria um loop infinito no tempo de compilação :

Um bloco de código BEGIN é executado o mais rápido possível, ou seja, no momento em que é completamente definido, mesmo antes de o restante do arquivo (ou string) contido ser analisado.

(de perlmod )

E é por isso que o Perl não consegue concluir a análise do código. Isso não termina:

$ perl -MO=Deparse -e 'BEGIN{1while 1}'

J

Isso segmenta o interpretador J (pelo menos no Linux):

15!:1[3#2

Ele tenta ler do endereço de memória 2. Curiosamente, se você tentar com 0 ou 1, você consegue domain error.

TeX

\def\x{\x}\x

TeX é uma linguagem de macroexpansão. Aqui, definimos a expansão da macro \xpara ser \xnovamente e, depois, adicionamos uma invocação de \x. TeX fica preso indefinidamente substituindo \xcom \x.

Esquema

(define-syntax s
    (syntax-rules ()
        ((_ (t) ...) (s (t t) ... (t t) ...))
        ((_ (t u) ...) (s (t) ... (u) ...))))
(s (+))

Meu compilador, Chicken, cometeu o erro de tentar expandir macros em tempo de compilação para "desempenho em tempo de execução" ou algo assim. Então pagou o preço de expandir este. Eu li o R5RS. Ninguém disse que as macros tinham que ser expandidas em tempo de compilação.

Essencialmente, o que está acontecendo é que a macro se expande para uma expressão de tamanho infinito, constantemente dobrando de tamanho. Bem, para ser técnico, dobrando todas as outras expansões. O destino do compilador está selado. Pelo menos no meu sistema, o Chicken caps de 2GB fica parado por um longo tempo tentando coletar lixo e depois trava depois que o coletor de lixo desiste. Demora um pouco, por causa de toda a mágica higiênica computacionalmente dispendiosa que ocorre.

Alternando entre expressões do formulário

(s (+) (+) (+) (+) ....

e

(s (+ +) (+ +) (+ +) (+ +) ....

parece aumentar drasticamente a taxa de consumo de memória em comparação com:

(define-syntax s
    (syntax-rules ()
        ((_ t ...) (s t ... t ...))))
(s +)

Suspeito que Chicken seja um compilador bastante resistente que tem algumas maneiras de evitar uma análise profunda de expressões sintáticas quando ele pode se safar, mas minha solução final obriga o pesquisador de padrões a realmente mergulhar.

Lisp comum

As macros facilitam:

(defmacro loop-forever ()
  (loop for x from 0 collecting x))

(defun compile-me ()
  (loop-forever))

compile-meChamadas de compilação loop-forever, que esgotam a memória da pilha durante sua expansão e travam o compilador. Se você quiser apenas fazer o compilador travar indefinidamente, então esta definição loop-foreverfará:

(defmacro loop-forever ()
  (loop))

Isso deve funcionar usando qualquer implementação de CL, a menos que o seu seja extremamente inteligente e possa detectar loops infinitos simples, mas duvido seriamente que faça isso. A proteção total contra isso é impossível, é claro.

PHP 5.3.1 (interpretador Segfaults) ( Bug 50261 , corrigido em 5.3.3)

   classe testClass
   {
       função testClass ()
       {
           echo 'String de saída!';
       }
   }

   classe testClass2 estende testClass
   {
       função __construct ()
       {
           call_user_func (array ('pai', '__construct'));
       }
   }

   novo testClass2;

Esse foi um problema, porque o código acima era comum em grande parte do código com o qual eu estava trabalhando, tornando esse um problema bastante difundido para nós.

(Se bem me lembro, em um ponto, essa foi a única maneira de chamar construtores-pai em PHP.)

D

(Compilador DMD32 D v2.067.1, compilação do Windows)

enum x = "mixin(x);";
mixin(x);

Observe que isso enviará o compilador para um loop infinito e o travará.

Erro: falta de memória

O snail mecânico sugeriu que os recursos de programação em tempo de compilação em D poderiam ser abusados ​​para esse fim, mas a solução é talvez mais simples do que o tipo de técnicas que ele tinha em mente.

Para aqueles que não estão familiarizados com 'mixins de strings', é um recurso macro bastante simples. Quando o compilador encontra mixin("asdf"), ele o substitui pelo conteúdo da string asdfe tenta compilá-lo novamente.

A solução acima será expandida como:

mixin(x);  ->  mixin("mixin(x);");  ->  mixin(x);

Portanto, a menos que o compilador tente detectar esse caso de expansão para o mesmo, ele entrará em um loop infinito de expansão.

Perl

Isso define a sobrecarga do operador no momento da compilação e executa o código no momento da compilação, que adiciona as instâncias da classe.

(a propósito, a recursão normalmente infinita consumiria toda a memória, mas com sobrecarga, ela trava)

package MyAmazingClass;
use 5.010;

use overload '+' => sub {
    my ($first, $second) = @_;
    return $first + $second;
};

sub new {
    my $self = shift;
    return bless {}, $self;
}

# BEGIN runs code at compile time
BEGIN {
    my $instance = MyAmazingClass->new;
    my $sum = $instance + $instance;
    say $sum;
}

Resultado:

fish: Job 1, 'perl' terminated by signal SIGSEGV (Address boundary error)

Simplex v.0.5 , 2 bytes

Pena que este não é um código de golfe :

2Q

Deixe-me explicar. Dos documentos:

[ Q] Adiciona o código fonte do programa ao programa externo, desde o início (excluindo caracteres!, Se o byte atual não for zero) Se byte for 2, também duplicará o comando atual.

Assim:

2 ~~ Manhattan adds 2 to the current byte: 10*0 + 2 = 2.
Q ~~ Adds program source code to the outer program, with Q

O programa externo é um pequeno recurso interessante no Simplex: é avaliado no final do programa. Então, se acompanharmos ...:

P1  P2  P3  P4  ...
2Q->2Q->2Q->2Q->...

Eventualmente, a memória acabará e o mundo terminará.

Clang ++

Acabei de encontrar esse bug divertido.

#include <iostream>
#include <string>
#include <sstream>
#include <fstream>

std::stringstream prog;

constexpr unsigned c_strlen( char const* str, unsigned count = 0 )
{
    return ('\0' == str[0]) ? count : c_strlen(str+1, count+1);
}

template < char t_c, char... tt_c >
struct rec_eval
{
    static void eval()
    {
        rec_eval<t_c>::eval();
        rec_eval < tt_c... > :: eval ();
    }
};
template < char t_c >
struct rec_eval < t_c >
{
    static void eval() {
        switch(t_c) {
            case '+':
                prog<<"++t[i];";
                break;
            case '-':
                prog<<"--t[i];";
                break;
            case '>':
                prog<<"++i;";
                break;
            case '<':
                prog<<"--i;";
                break;
            case '[':
                prog<<"while(t[i]){";
                break;
            case ']':
                prog<<"}";
                break;
            case '.':
                prog<<"putc(t[i],stdout);";
                break;
            case ',':
                prog<<"t[i]=getchar();";
                break;
        }
    }
};

template < char... tt_c >
struct exploded_string
{
    static void eval()
    {
        rec_eval < tt_c... > :: eval();
    }
};
template < typename T_StrProvider, unsigned t_len, char... tt_c >
struct explode_impl
{
    using result =
        typename explode_impl < T_StrProvider, t_len-1,
                                T_StrProvider::str()[t_len-1],
                                tt_c... > :: result;
};

template < typename T_StrProvider, char... tt_c >
struct explode_impl < T_StrProvider, 0, tt_c... >
{
     using result = exploded_string < tt_c... >;
};

template < typename T_StrProvider >
using explode =
    typename explode_impl < T_StrProvider,
                            c_strlen(T_StrProvider::str()) > :: result;


int main(int argc, char** argv)
{
    if(argc < 2) return 1;
    prog << "#include <stdio.h>\n#include <stdlib.h>\nint main(){unsigned char* t=calloc(";
    prog << (1 << sizeof(unsigned short));
    prog << ",sizeof(unsigned short));unsigned short i=0;";

    struct my_str_provider
    {
        constexpr static char const* str() { return "++++[>+++++<-]>+++[[>+>+<<-]>++++++[<+>-]+++++++++[<++++++++++>-]>[<+>-]<-]+++>+++++++++[<+++++++++>-]>++++++[<++++++++>-]<--[>+>+<<-]>>[<<+>>-]<-->>++++[<++++++++>-]++++++++++>+++++++++[>+++++++++++<-]>[[>+>+>+<<<-]>[<+>-]>>[[>+>+<<-]>>[<<+>>-]<[<->-[<->-[<->-[<->-[<->-[<->-[<->-[<->-[<->-[<<<+>---------->->[-]]]]]]]]]]]<]<<[>>++++++++++++[<++++<++++>>-]<<[.[-]>]<<]>[<++++++[>++++++++<-]>.[-]]<<<<<.<<<<<.[<]>>>>>>>>>.<<<<<..>>>>>>>>.>>>>>>>.[>]>[>+>+<<-]>[<+>-]>[-[[-]+++++++++[<+++++++++++++>-]<--.[-]>]]<<<<<.[<]>>>>>>>>>.>>>>>>>>>.[>]<<.<<<<<.<<<..[<]>>>>>>.[>]<<.[<]>>>>>>>>>.>.[>]<<.[<]>>>>.>>>>>>>>>>>>.>>>.[>]<<.[<]>.[>]<<<<<<.<<<<<<<<<<<..[>]<<<.>.[>]>[>+>+>+<<<-]>[<+>-]>>[[>+>+<<-]>>[<<+>>-]<[<->-[<->-[<->-[<->-[<->-[<->-[<->-[<->-[<->-[<<<+>---------->->[-]]]]]]]]]]]<]<<[>>++++++++++++[<++++<++++>>-]<<[.[-]>]<<]>[<++++++[>++++++++<-]>.[-]]<<<<<.<<<<<.[<]>>>>>>>>>.<<<<<..>>>>>>>>.>>>>>>>.[>]>[>+>+<<-]>[<+>-]>[-[[-]+++++++++[<+++++++++++++>-]<--.[-]>]]<<<<<.[<]>>>>>>>>>.>>>>>>>>>.[>]<<.<<<<<.<<<..[<]>>>>>>.[>]<<<<.>>>.<<<<.<.<<<<<<<<<<.>>>>>>.[>]<<.[<]>>>>>>>>>.>.>>>>>>>>>.[>]<<.<<<<<<<.[<]>>>>>>>>>.[<]>.>>>>>>>>>.[>]<<.<<<<.<<<<<<<<<<<<<.[>]<<<<<<<<<.[>]<<.[<]>>>>>>>>.[>]<<<<<<.[<]>>>>>..[>]<<.<<<<<<<<<<<<.[<]>>>>.[>]<<.<<<<.[<]>>>>>>.>>>.<<<<<<.>>>>>>>.>>>>>>>>>>.[>]<<<.>.>>>-[>+>+>+<<<-]>[<+>-]>>[[>+>+<<-]>>[<<+>>-]<[<->-[<->-[<->-[<->-[<->-[<->-[<->-[<->-[<->-[<<<+>---------->->[-]]]]]]]]]]]<]<<[>>++++++++++++[<++++<++++>>-]<<[.[-]>]<<]>[<++++++[>++++++++<-]>.[-]]<<[>+>+<<-]>[<+>-]+>[<->[-]]<[-<<<[<]>>>>>>>>>>.<.[>]<<.[<]>>>>>>>>>>>.<<.<<<.[>]<<<<<<<<<<.[>]>>]<<<<.<<<<<.[<]>>>>>>>>>.<<<<<..>>>>>>>>.>>>>>>>.[>]>[>+>+<<-]>[<+>-]+>[<->-[<+>[-]]]<[++++++++[>+++++++++++++<-]>--.[-]<]<<<<.[<]>>>>>>>>>.>>>>>>>>>.[>]<<.<<<<<.<<<..[<]>>>>>>.[>]<<.[<]>>>>>>>>>.>.[>]<<.[<]>>>>.>>>>>>>>>>>>.>>>.[>]<<.[<]>.[>]<<<<<<.<<<<<<<<<<<..[>]<<<<.>>>..>>]"; }
    };

    auto my_str = explode < my_str_provider >{};
    my_str.eval();

    prog << "}";

    std::ofstream ofs(argv[1]);
    if(!ofs) return 2;
    ofs << prog.str() << std::endl;
    ofs.close();

    return 0;
}

O objetivo é traduzir o Brainfuck em C, usando a meta-programação de modelos para fazer a maior parte do trabalho. Esse código funciona para programas menores do Brainfuck, como o Hello World, mas quando tentei executá-lo com 99 garrafas ...

$ clang++ -std=c++11 -fconstexpr-depth=1000 bf_static.cpp
clang: error: unable to execute command: Segmentation fault (core dumped)
clang: error: clang frontend command failed due to signal (use -v to see invocation)
clang version 3.5.2 (tags/RELEASE_352/final)
Target: i386-pc-windows-cygnus
Thread model: posix
clang: note: diagnostic msg: PLEASE submit a bug report to http://llvm.org/bugs/ and include the crash backtrace, preprocessed source, and associated run script.
clang: note: diagnostic msg:
********************

PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT:
Preprocessed source(s) and associated run script(s) are located at:
clang: note: diagnostic msg: /tmp/bf_static-afa982.cpp
clang: note: diagnostic msg: /tmp/bf_static-afa982.sh
clang: note: diagnostic msg:

********************

Ele será compilado com êxito no GCC (após cerca de 2 minutos), mas vinculá-lo causa outro problema ...

/usr/lib/gcc/i686-pc-cygwin/4.9.3/../../../../i686-pc-cygwin/bin/as: /tmp/cc0W7cJu.o: 
section .eh_frame$_ZN8rec_eval<giant mangled name removed>: string table overflow at offset 10004228
/tmp/cc3JeiMp.s: Assembler messages:
/tmp/cc3JeiMp.s: Fatal error: can't close /tmp/cc0W7cJu.o: File too big

Opa

Smalltalk (Squeak dialect, versão 4.x)

Muito fácil, basta avaliar isso ou aceitar um método com esse literal

1.0e99999999999999999999

Ele tentará avaliar a potência de 10 na aritmética de número inteiro grande, apenas para arredondar corretamente inf Tsss;)

Edit: quantos 9 são necessários?

Como 2 ^ 10 é 1024, aproximadamente 10 ^ 3, podemos aproximar aproximadamente 10 ^ n por 2 ^ (10 * n / 3). Isso significa que 10 ^ n exige que 10 * n / 3 bits sejam representados em binário. Gostaríamos de ter 10 ^ n não representável.

Assumindo ponteiros de 32 bits para a memória do objeto, sabemos que não podemos endereçar mais de 2 ^ 32 bytes, ou seja, 2 ^ 35 bits. Então, vamos reverter o problema: 2 ^ 35 é aproximadamente 32 * 2 ^ 30, 32 * 10 ^ 9. Isso requer cerca de 11 dígitos decimais; portanto, com onze 9, temos a certeza de gerar um erro no Squeak de 32 bits. Em 64 bits, isso seria vinte e um 9.

Também podemos esgotar a memória com menos 9s, todo o espaço endereçável não está necessariamente disponível, mas é mortalmente lento para testar, a Squeak VM não é otimizada para uma aritmética gigante diferente da GMP.

Este é o meu método original e conciso para travar o GolfScript:

{1.}do

O que isso faz é configurar um loop para sempre que continua pressionando 1 na pilha até a memória acabar.

Em C / C ++, acredito que esse trecho de código original travaria o compilador:

#define a bb
#define b aa
int main(){a}

Isso faria com que o compilador travasse dobrando a quantidade de a e transformando-os em b e vice-versa, de modo que o compilador logo ficaria sem memória e travaria.

Outro é para lote no Windows, se congelar completamente o computador, em vez de apenas o próprio script em lote contar. Você deve digitar o seguinte:

:a
start %0
goto a

Isso entra em um ciclo infinito de fazer cópias de si mesmo, que fazem cópias de si mesmos e assim por diante. Provavelmente, isso poderia eventualmente travar seu computador se você executasse esse pequeno código.

Um último é uma bomba VBS. É outra bomba, como a última, mas abre uma quantidade infinita de caixas de diálogo.

set oshell = wscript.createobject("wscript.shell")
do
oshell.run "wscript " & wscript.scriptname
msgbox "blah"
loop

Isso cria continuamente uma cópia de si mesmo e abre uma caixa de mensagem em um loop infinito, o que os clones também fazem. A execução desses dois últimos programas não é recomendada, pois eles podem congelar o computador e fazer com que você precise inicializar com força o computador.

Observe que eu mesmo criei todos esses programas.

Lisp comum, 8 bytes

Mais curto que a outra resposta do Common Lisp :-)

#.(loop)

Faça um loop enquanto lê seu formulário.

O padrão Common Lisp não menciona uma maneira portátil de fazê-lo falhar, então acho que precisamos ter uma maneira definida pela implementação. Ainda 8 bytes:

#.(quit) ; ccl

... ou

#.(exit) ; sbcl

Quando você liga (compile-file "crash.lisp"), os ambientes misteriosamente "travam".

Brincadeiras à parte, ainda estou tentando encontrar uma maneira de realmente danificar o ambiente (e em breve), mas é realmente difícil. Tudo o que recebo é uma boa interação com o depurador.

x86 asm

"nasm -v" retorna "NASM versão 2.11.08 compilada em 21 de fevereiro de 2015" (estou executando-o no win7)

O montador está rodando há 1:12:27 até agora em um i7, saturando totalmente um dos núcleos. O arquivo de saída está sentado em 0 bytes, o consumo de memória está estável em 1.004K - parece seguro dizer que eu acabei com tudo, em vez de apenas dar a ele uma tarefa muito, muito longa. :)

A chave do truque é o valor de repetição na macro - 0xFFFFFFFF. No entanto, eu não estou familiarizado o suficiente com os internos de Nasm para saber por que exatamente isso está sufocando. Eu esperava obter uma saída de ~ 16 GB há uma hora.

%MACRO INVOKE 1-*
;  %REP    %0 - 1
  %REP     0xffffffff
    %ROTATE   -1
    PUSH    DWORD %1
  %ENDREP
  %ROTATE -1
  CALL    %1
%ENDMACRO

[section .text]
bits 32
org 0x10000

EntryPoint:
    INVOKE dword 666
    ret

EDIT: Apenas verifiquei o gerenciador de tarefas, o Nasm está em execução há 7:40:41 e a memória está agora em 1.016K

Assembler Gnu, gerando enormes arquivos de saída

Essa macro tenta preencher o arquivo de saída com lixo (geralmente bytes nulos) até que um limite de 4 GB seja atingido, adiciona um int para ultrapassar esse limite e se chama recursivamente para continuar preenchendo a saída com pedaços de lixo de 4 GB. Isso encherá seu disco rígido até que esteja cheio; nesse ponto, o montador provavelmente travará.

.macro f n #Define a macro named f, taking argument n.
.p2align 32 #Fill file with 0x00's until current address is divisible by 2^32
.long 0 #Add a long after the current address, throwing it off alignment.
.if \n #If n > 0, recursively tail-call itself, decrementing n.
f "(\n-1)"
.endif
.endm #End macro definition.
f 32 #Expand macro f, with n = 32 (output size 4GB*32 = 128GB)

Observe que a recursão infinita não pode ser usada, pois o assembler captura esse caso especial e para de expandir a macro.

A compilação pode ser feita as -o crash.out crash.sna maioria das distribuições Linux.

Lisp comum, 29 bytes

Implementação: Clozure CL

AVISO: Tenha cuidado ao executar esse código, pois isso pode matar os processos que você não deseja!

#.(run-program"pkill"'("cl"))

Isso executa o comando shell pkill clno tempo de compilação, o que matará o processo Lisp fazendo a compilação. Tecnicamente, não é um acidente, mas tem o mesmo efeito.

Exemplo de uso:

$ cat /tmp/t.lisp
#.(run-program "pkill" '("cl"))
$ ccl -n
Welcome to Clozure Common Lisp Version 1.11-dev-r16513-trunk  (LinuxX8664)!

? (compile-file "/tmp/t.lisp")
#P"/tmp/t.lx64fsl"
NIL
NIL
?
zsh: terminated  ccl -n
$ 

Felix

Isso não funciona mais, mas em um ponto, este código:

include "std/control/pchannels";

fun is_square(v: int) => let s = int$ sqrt$ v.float + 0.5f in s*s == v;
fun is_median(v: int) => v % 4 == 0 and (v/4).is_square;

struct Message { value: int; };

proc process(c: int, chan: pchannel[Message]) {
    var i = 0;
    for var b in (c+1)/2 upto c do
        for var a in c - b + 1 upto b do
            if is_median(2*(b*b+c*c)-a*a) or
               is_median(2*(a*a+c*c)-b*b) or
               is_median(2*(a*a+b*b)-c*c) do ++i; done;
        done
    done
    write(chan, Message i);
};

proc main() {
    n := int$ System::argv 1;
    var count = n;
    chan := #mk_pchannel[Message];
    var ntri = 0;

    for var c in 1 upto n perform spawn_pthread { process(c, chan); };

    while count > 0 do
        let v = chan.read in ntri += v.value;
        --count;
    done
    ntri.println;
}

main;

Isso daria um grande erro:

inner_bind_expression raised Not_found [BUG] e=(&((main_mf_60270<60270> ())), (value v))

FALHA DO SISTEMA bind_expression 'raise Not_found [BUG] Compilação Felix "/ media / ryan / stuff / felix / build / release / host / bin / flxg" "-q" "--optimise" "--inline = 100" "- output_dir = / home / ryan / stuff / .felix / text "" --cache_dir = / home / ryan / stuff / .felix / cache "" -I / mídia / ryan / stuff / felix / build / release / compartilhamento / lib "" -I / media / ryan / stuff / felix / build / release / host / lib "" --syntax=@/media/ryan/stuff/felix/build/release/share/lib/grammar/grammar.files " "--automaton = / home / ryan / stuff / .felix / cache / mídia / ryan / stuff / felix / build / release / share / lib / gramática / grammar.files / syntax.automaton" "--import = plat / flx.flxh "" std "" /home/ryan/golf/itri/sl.flx "falhou Erro 1 na flx: [strerror_r] Falha ao localizar texto para o erro número 1

A questão estava aqui:

let v = chan.read in ntri += v.value;

letesperava uma expressão para segui-lo, mas eu coloquei uma declaração. Então o compilador assustou um pouco.

Mais informações em https://groups.google.com/forum/m/#!topic/felix-language/J3Hs4j6E0gM .

Javascript

while (true === true){
console.log(0);
}

Isso o envia para um loop infinito. Eu usei o compilador Codecademy JS e ele travou o meu navegador.

Javascript

function crash(){
  window.location.hash=Math.random(),onhashchange=function(){crash()}
}

Este trava os navegadores da web de uma maneira seriamente eficaz. USE POR SUA CONTA E RISCO!!!

Hássio

Arquivo1.tem:

use "File2.has";

Arquivo2.tem:

use "File1.has";

Isso faz com que o Hassium carregue e comece a compilar o File2.has, que instrui o carregamento do File1.has, o que faz com que o File2.has seja carregado, e assim por diante.

LOLCODE 1.2, Intérprete / Compilador Comum LOLCODE (lci)

Eu sei que isso não é código-golfe, mas é extremamente curto de qualquer maneira.

OBTW

Isso faz com que o sinal 11:

Segmentation fault (core dumped)

Por quê? HAI1.2indica o início do programa e OBTWinicia um comentário multilinha. Mas o compilador espera que KTHXBYEa feche o HAIe TLDRa feche o comentário multilinha.

Observe que isso ainda funcionará para causar segfault com algo diferente de TLDRdepois OBTW.

(Pelos padrões da wikipedia , LOLCODE é apenas um estranho, não é realmente esotérico.)
Você pode pegar o intérprete em git / justinmeza / lci .