Escriba un código perfectamente legal en un lenguaje decente de su elección cuya compilación bloqueará el compilador o lo enviará a un bucle infinito (tiempo de compilación infinito).

Restricciones

• Use un lenguaje estándar que se use en el mundo real.
• Use un compilador estándar y bien desarrollado (no hay respuestas como "Escribí mi compilador de C que falla en todo").
• El código debe ser legal en el idioma (lo más probable es que tenga que explotar un compilador o un error de idioma).
• Déle a su compilador la versión y las opciones utilizadas para que otros puedan replicarlo.
• Explica por qué el compilador se bloqueó, si es posible.

Que te diviertas :)

Estoy bastante seguro de que se ha solucionado ahora, pero solía ser que podía bloquear el compilador de Java (o, bloquear Eclipse) escribiendo

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

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

En realidad, de acuerdo con esa página, el compilador simplemente se bloqueará, no se bloqueará. Aún así, pensé que era muy divertido.

Mi solución favorita para 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.hsy ghc Bad.hsbucle infinito. GHC 7.4.1 realiza un bucle infinito cuando ghc -O2 Bad.hsse ejecuta.

Explicación: omega se define utilizando una recursión infinita (la única forma en que puede habitar cualquier tipo). El compilador del compilador ve xxcomo una función simple, no recursiva, por lo que intenta incluirlo en la definición de omega. El resultado es (\x@(C x') -> x' x) (C xx). Al ver una coincidencia de patrones en un constructor, el compilador intenta reducirlo, obteniendo xx (C xx)nuevamente bucles. El truco es que en xxrealidad es recursivo, pero la recursión está oculta dentro del tipo de datos.

Nota: Mientras escribía el rompecabezas, olvidé que dejé GHC ejecutándose en el bucle infinito. Tomó toda mi memoria, se estrelló Firefox y apenas logré matarlo sin restablecimiento completo.

Esto es fácil en cualquier lenguaje de tipo dependiente . La verificación de tipos de tipos dependientes generales es indecidible ya que puede requerir cálculos arbitrariamente complejos (Turing-complete). Simplemente puede codificar en un tipo dependiente un valor demasiado grande. Luego, el verificador de tipos utilizará toda la memoria disponible y se bloqueará. Por ejemplo, en Coq, ReyCharles da el ejemplo deCompute 70000. , lo que hace que el verificador de tipos construya un número gigante de Peano y se bloquee.

En lenguajes más comunes que admiten algún tipo de macro expansión o metaprogramación, puede hacer algo similar. Por ejemplo, puede usar toda la memoria disponible en 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 }

El lenguaje de programación D permite la ejecución de funciones en tiempo de compilación . Esto se puede usar para calcular algo en tiempo de compilación que es demasiado grande para caber en la memoria. Algo similar se puede lograr usando la metaprogramación de plantillas C ++.

En XML (no es un lenguaje de programación compilado, pero un procesador XML es análogo a un compilador), las entidades en expansión pueden hacer que el procesador se quede sin memoria:

<?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>

Esto se llama el ataque de mil millones de risas .

C#

Encontré esto en una pregunta 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)))))));
    }
}

El compilador eventualmente se bloqueará.

El problema parece estar relacionado con la inferencia de tipos y / o la generación lambda combinada con la resolución de sobrecarga.

VBA

¿qué tal si puedes bloquear el IDE escribiendo código?

en cualquier aplicación de Microsoft Office, intente esto:

ALT+ F11para llegar a la ventana de VBA, luego intente el siguiente código

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

y he aquí

¡Simplemente puede escribir redim preserve v(,1 to 5)en la ventana inmediata y se bloqueará después de presionar ENTER!

Perl (15)

BEGIN{1while 1}

Esto crea un bucle infinito en tiempo de compilación :

Se ejecuta un bloque de código BEGIN lo antes posible, es decir, en el momento en que se define por completo, incluso antes de analizar el resto del archivo (o cadena) que lo contiene.

(de perlmod )

Y es por eso que Perl no puede completar el análisis del código. Esto no termina:

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

J

Esto pone en peligro al intérprete J (al menos en Linux):

15!:1[3#2

Intenta leer desde la dirección de memoria 2. Curiosamente, si lo intentas con 0 o 1, obtienes domain error.

Texas

\def\x{\x}\x

TeX es un lenguaje de macroexpansión. Aquí definimos la expansión de la macro \xpara que sea \xnuevamente, y luego agregamos luego una invocación de \x. TeX se atasca interminablemente reemplazando \xcon \x.

Esquema

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

Mi compilador, Chicken, cometió el error de intentar expandir macros en tiempo de compilación para "rendimiento en tiempo de ejecución" o algo así. Entonces pagó el precio de expandir este. He leído R5RS. Nadie dijo que las macros debían expandirse en tiempo de compilación.

Esencialmente, lo que está sucediendo es que la macro se expande a una expresión de tamaño infinito, duplicando constantemente su tamaño. Bueno, para ser técnico, duplicar cualquier otra expansión. El destino del compilador está sellado. Al menos en mi sistema, Chicken caps a 2GB, se detiene durante mucho tiempo tratando de recolectar basura, luego se bloquea después de que el recolector de basura se rinde. Sin embargo, lleva un tiempo debido a toda la magia higiénica computacionalmente costosa que ocurre.

Cambiar entre expresiones de la forma

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

y

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

parece aumentar muy, muy dramáticamente la tasa de consumo de memoria en comparación con:

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

Sospecho que Chicken es un compilador bastante robusto que tiene algunas formas de evitar un análisis profundo de las expresiones sintácticas cuando puede salirse con la suya, pero mi solución final obliga al patrón de patrones a sumergirse realmente.

Lisp común

Las macros lo hacen fácil:

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

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

Compilar compile-mellamadas loop-forever, que agota la memoria de almacenamiento dinámico durante su expansión y bloquea el compilador. Si solo desea que el compilador se cuelgue indefinidamente, entonces esta definición de loop-foreverlo hará:

(defmacro loop-forever ()
  (loop))

Esto debería funcionar con cualquier implementación de CL, a menos que la suya sea extremadamente inteligente y pueda detectar bucles infinitos simples, pero dudo seriamente que alguno haga esto. La protección total contra esto es imposible, por supuesto.

PHP 5.3.1 (intérprete de Segfaults) ( error 50261 , corregido en 5.3.3)

   clase testClass
   {
       función testClass ()
       {
           echo 'Cadena de salida!';
       }
   }

   clase testClass2 extiende testClass
   {
       función __construct ()
       {
           call_user_func (array ('parent', '__construct'));
       }
   }

   nuevo testClass2;

Este fue un pequeño problema, porque el código anterior era común en muchos de los códigos con los que estaba trabajando, por lo que este es un problema bastante extendido para nosotros.

(Si recuerdo correctamente, en un momento esta era la única forma de llamar a los constructores principales en PHP).

re

(Compilador DMD32 D v2.067.1, compilación de Windows)

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

Tenga en cuenta que esto enviará el compilador a un bucle infinito y lo bloqueará.

Error: sin memoria

El caracol mecánico sugirió que las funciones de programación en tiempo de compilación en D podrían ser abusadas para este propósito, pero la solución es quizás más simple que el tipo de técnicas que tenía en mente.

Para aquellos que no están familiarizados con los 'mixins de cadenas', es una característica macro bastante sencilla. Cuando el compilador se encuentra mixin("asdf"), lo sustituye con el contenido de la cadena asdfe intenta compilarlo nuevamente.

La solución anterior se expandirá como:

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

Entonces, a menos que el compilador intente detectar este caso de expandir a mismo, entrará en un bucle infinito de expansión.

Perl

Esto define la sobrecarga del operador en tiempo de compilación, y ejecuta código en tiempo de compilación que agrega las instancias de clase juntas.

(por cierto, normalmente la recursión infinita se comería toda la memoria, pero con una sobrecarga, simplemente se bloquea)

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;
}

Salida:

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

Simplex v.0.5 , 2 bytes

Lástima que esto no sea un código de golf :

2Q

Dejame explicar. De los documentos:

[ Q] Agrega el código fuente del programa al programa externo, desde el principio (excluyendo los caracteres!, Si el byte actual no es cero) Si el byte es 2, también duplica el comando actual.

Entonces:

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

El programa externo es una pequeña característica en Simplex: se evalúa al final del programa. Entonces, si hacemos un seguimiento ...:

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

Eventualmente, la memoria se acabará y el mundo terminará.

Clang ++

Acabo de encontrar este divertido insecto.

#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;
}

El objetivo es traducir Brainfuck a C, usando metaprogramación de plantillas para hacer la mayor parte del trabajo. Este código funciona para programas más pequeños de Brainfuck, como Hello World, pero cuando intenté ejecutarlo con 99 botellas ...

$ 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:

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

Se compilará correctamente en GCC (después de aproximadamente 2 minutos), pero vincularlo causa otro 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

Ups

Smalltalk (dialecto Squeak, versión 4.x)

Muy fácil, solo evalúa esto o acepta un método con este literal

1.0e99999999999999999999

Intentará evaluar la potencia de 10 en aritmética de enteros grandes, solo para redondear correctamente inf Tsss;)

Editar: ¿cuántos 9 son necesarios?

Como 2 ^ 10 es 1024, aproximadamente 10 ^ 3, podemos aproximar aproximadamente 10 ^ n por 2 ^ (10 * n / 3). Eso significa que 10 ^ n requieren 10 * n / 3 bits para representarse en binario. Nos gustaría tener 10 ^ n no representable.

Suponiendo punteros de 32 bits para la memoria del objeto, sabemos que no podemos direccionar más de 2 ^ 32 bytes, es decir 2 ^ 35 bits. Entonces, invirtamos el problema: 2 ^ 35 es aproximadamente 32 * 2 ^ 30, 32 * 10 ^ 9. Eso requiere aproximadamente 11 dígitos decimales, por lo que con once 9, estamos seguros de generar un error en Squeak de 32 bits. En 64 bits serían veintiuno 9.

También podemos agotar la memoria con menos 9 segundos, todo el espacio direccionable no está necesariamente disponible, pero es muy lento de probar, el Squeak VM no está optimizado para una aritmética tan gigante a diferencia de GMP.

Este es mi método original y conciso para bloquear GolfScript:

{1.}do

Lo que esto hace es configurar un bucle para siempre que sigue presionando 1 en la pila hasta que se agote la memoria.

En C / C ++, creo que este código original bloqueará el compilador:

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

Esto haría que el compilador se atascara duplicando la cantidad de a y convirtiéndolos en b y viceversa, por lo que el compilador pronto se quedará sin memoria y se bloqueará.

Otro es para lotes en Windows, si el congelamiento completo de la computadora en lugar de solo el script por lotes en sí mismo cuenta. Debe escribir lo siguiente:

:a
start %0
goto a

Esto entra en un ciclo infinito de hacer copias de sí mismo, que hacen copias de sí mismos, etc. Esto probablemente bloqueará su computadora si ejecuta este pequeño código.

Una última es una bomba VBS. Es otra bomba, como la última, pero en su lugar abre una cantidad infinita de cuadros de diálogo.

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

Esto crea continuamente una copia de sí mismo y abre un cuadro de mensaje en un bucle infinito, lo que también hacen los clones. No se recomienda ejecutar estos dos últimos programas, ya que pueden congelar su computadora y hacer que tenga que arrancarla.

Tenga en cuenta que se me ocurrió todos estos programas yo mismo.

Lisp común, 8 bytes

Más corta que la otra respuesta de Common Lisp :-)

#.(loop)

Bucle mientras lee su formulario.

El estándar Common Lisp no menciona una forma portátil de hacer que se bloquee, por lo que creo que necesitamos tener una forma definida por la implementación. Todavía 8 bytes:

#.(quit) ; ccl

... o

#.(exit) ; sbcl

Cuando llamas (compile-file "crash.lisp"), los entornos misteriosamente "chocan".

Bromeando, todavía estoy tratando de encontrar una manera de bloquear realmente el medio ambiente (y en breve), pero es realmente difícil. Todo lo que obtengo es una buena interacción con el depurador.

x86 asm

"nasm -v" devuelve "NASM versión 2.11.08 compilada el 21 de febrero de 2015" (lo estoy ejecutando en win7)

El ensamblador ha estado funcionando durante 1:12:27 hasta ahora en un i7, saturando totalmente uno de los núcleos. El archivo de salida se encuentra en 0 bytes, el consumo de memoria se ha mantenido estable en 1,004K, parece seguro decir que he superado a Nasm, en lugar de simplemente darle una tarea muy, muy larga. :)

La clave del truco es el valor de repetición en la macro: 0xFFFFFFFF. Sin embargo, no estoy lo suficientemente familiarizado con las partes internas de Nasm para saber por qué exactamente se está ahogando con esto. Esperaba obtener una salida de ~ 16 GB hace una 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

EDITAR: acabo de comprobar el administrador de tareas, Nasm ha estado funcionando durante 7:40:41 y la memoria ahora es de hasta 1,016K

Ensamblador de GNU, generando grandes archivos de salida

Esta macro intenta llenar el archivo de salida con basura (generalmente bytes nulos) hasta que se alcanza un límite de 4 GB, agrega un int para superar ese límite y recursivamente se llama a sí mismo para seguir llenando la salida con trozos de basura de 4 GB. Esto llenará su disco duro hasta que esté lleno, momento en el cual el ensamblador probablemente se bloqueará.

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

Tenga en cuenta que no se puede utilizar la recursión infinita, ya que el ensamblador captará ese caso especial y dejará de expandir la macro.

La compilación se puede hacer con la as -o crash.out crash.smayoría de las distribuciones de Linux.

Lisp común, 29 bytes

Implementación: Clozure CL

ADVERTENCIA: ¡ Tenga cuidado al ejecutar este código, puede matar procesos que no desea!

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

Esto ejecuta el comando de shell pkill clen tiempo de compilación, que matará el proceso Lisp que realiza la compilación. No es técnicamente un accidente, pero tiene el mismo efecto.

Ejemplo 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

Esto ya no funciona, pero en un momento, 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;

Esto daría un gran error:

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

FALLO DEL SISTEMA bind_expression 'elevado Not_found [ERROR] Compilación 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 / media / ryan / stuff / felix / build / release / share / 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 / media / ryan / stuff / felix / build / release / share / lib / grammar / grammar.files / syntax.automaton" "--import = plat / flx.flxh "" std "" /home/ryan/golf/itri/sl.flx "falló Error 1 en flx: [strerror_r] Error al encontrar el texto para el error número 1

El problema estaba aquí:

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

letesperaba que una expresión lo siguiera, pero puse una declaración en su lugar. Entonces el compilador se asustó un poco.

Más información en https://groups.google.com/forum/m/#!topic/felix-language/J3Hs4j6E0gM .

JavaScript

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

Esto lo envía a un bucle infinito. Usé el compilador Codecademy JS y se bloqueó mi navegador.

Javascript

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

Este bloquea los navegadores web de una manera realmente efectiva. ¡¡¡ÚSELO BAJO SU PROPIO RIESGO!!!

Hassium

File1.has:

use "File2.has";

File2.has:

use "File1.has";

Esto hace que Hassium se cargue y comience a compilar File2.has, que le dice que cargue File1.has, lo que hace que cargue File2.has, y así sucesivamente.

LOLCODE 1.2, LOLCODE Intérprete / Compilador Común (lci)

Sé que esto no es código golf, pero de todos modos es extremadamente corto.

OBTW

Esto causa la señal 11:

Segmentation fault (core dumped)

¿Por qué? HAI1.2denota el inicio del programa e OBTWinicia un comentario multilínea. Pero el compilador espera que KTHXBYEa cierre el HAI, y TLDRa que cierre el comentario multilínea.

Tenga en cuenta que esto seguirá funcionando para causar una falla predeterminada con cualquier otra cosa que no sea TLDRdespués OBTW.

(Según los estándares de wikipedia , LOLCODE es solo un Weirdlang, en realidad no esotérico).
Puede obtener el intérprete de git / justinmeza / lci .