Scrivi un codice perfettamente legale in un linguaggio decente a tua scelta, la cui compilazione può causare l'arresto anomalo del compilatore o inviarlo in un ciclo infinito (tempo di compilazione infinito).

restrizioni:

• Utilizzare un linguaggio standard utilizzato nel mondo reale.
• Usa un compilatore standard ben sviluppato (nessuna risposta come "Ho scritto il mio compilatore C che si blocca su tutto").
• Il codice deve essere legale nella lingua (quindi molto probabilmente dovrai sfruttare un compilatore o un bug di lingua).
• Fornisci la versione del compilatore e le opzioni utilizzate in modo che altri possano replicarlo.
• Spiega perché il compilatore si è bloccato, se possibile.

Divertiti :)

Sono abbastanza sicuro che sia stato risolto ora, ma era possibile che si potesse bloccare il compilatore Java (o, crash Eclipse) scrivendo

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

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

In realtà, secondo quella pagina, il compilatore si bloccherà e non si arresta. Tuttavia, ho pensato che fosse abbastanza divertente.

La mia soluzione preferita per 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

Per GHC 6.12.1 entrambi ghci Bad.hse ghc Bad.hsloop all'infinito. GHC 7.4.1 ghc -O2 Bad.hsesegue un ciclo infinito quando viene eseguito.

Spiegazione: omega è definita usando una ricorsione infinita (l'unico modo in cui può abitare qualsiasi tipo). L'interno del compilatore vede xxcome una funzione semplice e non ricorsiva, quindi cerca di incorporarlo nella definizione di omega. Ne risulta (\x@(C x') -> x' x) (C xx). Vedendo una corrispondenza del modello su un costruttore, il compilatore cerca di ridurla, ottenendo di xx (C xx)nuovo e loop. Il trucco è che in xxrealtà è ricorsivo, ma la ricorsione è nascosta all'interno del tipo di dati.

Nota: durante la scrittura del puzzle, ho dimenticato di aver lasciato GHC in esecuzione nel ciclo infinito. Mi ha preso tutta la mia memoria, ho bloccato Firefox e sono riuscito a malapena a ucciderlo senza hard reset.

Questo è facile in qualsiasi linguaggio tipicamente dipendente . Il controllo del tipo di tipi dipendenti generici è indecidibile in quanto potrebbe richiedere calcoli arbitrariamente complessi (Turing-complete). Puoi semplicemente codificare in un tipo dipendente un valore troppo grande. Quindi il controllo del tipo utilizzerà tutta la memoria disponibile e il crash. Ad esempio, in Coq, ReyCharles fornisce l'esempio diCompute 70000. , che fa sì che il controllo del tipo costruisca un numero Peano gigante e si blocchi.

In linguaggi più comuni che supportano una sorta di espansione macro o metaprogrammazione, puoi fare qualcosa di simile. Ad esempio, è possibile utilizzare tutta la memoria disponibile in 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 }

Il linguaggio di programmazione D consente l' esecuzione di funzioni in fase di compilazione . Questo può essere usato per calcolare qualcosa in fase di compilazione che è troppo grande per adattarsi alla memoria. Qualcosa di simile può essere ottenuto utilizzando la metaprogrammazione del modello C ++.

In XML (non un linguaggio di programmazione compilato, ma un processore XML è analogo a un compilatore), le entità in espansione possono far esaurire la memoria del processore:

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

Questo è chiamato l' attacco da miliardi di risate .

C #

Trovato questo su una domanda 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)))))));
    }
}

Il compilatore alla fine si arresterà in modo anomalo.

Il problema sembra correlato all'inferenza di tipo e / o alla generazione lambda combinata con la risoluzione del sovraccarico.

VBA

che ne dite se è possibile crash l'IDE digitando il codice?

in qualsiasi applicazione di Microsoft Office, prova questo:

ALT+ F11per accedere alla finestra VBA, quindi provare il codice seguente

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

ed ecco:

Puoi semplicemente digitare redim preserve v(,1 to 5)nella finestra immediata e si bloccherà dopo aver premuto ENTER!

Perl (15)

BEGIN{1while 1}

Questo crea un ciclo infinito in fase di compilazione :

Un blocco di codice BEGIN viene eseguito il più presto possibile, ovvero nel momento in cui è completamente definito, anche prima che venga analizzato il resto del file (o stringa) contenente.

(da perlmod )

Ed è per questo che Perl non è in grado di completare l'analisi del codice. Questo non termina:

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

J

Questo segfault l'interprete J (almeno su Linux):

15!:1[3#2

Prova a leggere dall'indirizzo di memoria 2. È interessante notare che se lo provi con 0 o 1, ottieni domain error.

TeX

\def\x{\x}\x

TeX è un linguaggio di macro-espansione. Qui definiamo l'espansione della macro \xper essere di \xnuovo, e quindi aggiungiamo in seguito un'invocazione di \x. TeX si blocca all'infinito sostituendolo \xcon \x.

schema

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

Il mio compilatore, Chicken, ha commesso l'errore di tentare di espandere le macro in fase di compilazione per "prestazioni di runtime" o qualcosa del genere. Quindi ha pagato il prezzo di espansione di questo. Ho letto R5RS. Nessuno ha detto che le macro dovevano essere espanse al momento della compilazione.

In sostanza quello che sta succedendo è che la macro si espande in un'espressione di dimensioni infinite, raddoppiando costantemente le dimensioni. Beh, per essere tecnico, raddoppiando ogni altra espansione. Il destino del compilatore è segnato. Almeno sul mio sistema, i tappi di pollo da 2 GB, si fermano a lungo nel tentativo di raccogliere la spazzatura, quindi si blocca dopo che il garbage collector si arrende. Ci vuole un po 'però a causa di tutta la magia igienica computazionalmente costosa che si verifica.

Passare tra le espressioni del modulo

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

e

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

sembra aumentare molto, molto drasticamente il tasso di consumo di memoria rispetto a:

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

Sospetto che Chicken sia un compilatore abbastanza robusto che ha alcuni modi per evitare un'analisi approfondita delle espressioni sintattiche quando può cavarsela, ma la mia soluzione finale obbliga il pattern matcher a immergersi davvero.

Lisp comune

Le macro lo rendono semplice:

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

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

compile-meChiamate di compilazione loop-forever, che esaurisce la memoria dell'heap durante la sua espansione e si arresta in modo anomalo nel compilatore. Se vuoi solo far sospendere indefinitamente il compilatore, allora questa definizione loop-foreverlo farà:

(defmacro loop-forever ()
  (loop))

Questo dovrebbe funzionare usando qualsiasi implementazione CL, a meno che la tua non sia estremamente intelligente e in grado di rilevare semplici cicli infiniti, ma dubito seriamente che qualsiasi cosa faccia. La protezione totale contro questo è impossibile, ovviamente.

PHP 5.3.1 (interprete Segfaults) ( Bug 50261 , corretto in 5.3.3)

   classe testClass
   {
       funzione testClass ()
       {
           echo 'Output string!';
       }
   }

   class testClass2 estende testClass
   {
       funzione __construct ()
       {
           call_user_func (array ('parent', '__construct'));
       }
   }

   nuovo testClass2;

Questo è stato un po 'un problema, perché il codice sopra era comune in gran parte del codice con cui stavo lavorando, rendendolo un problema abbastanza diffuso per noi.

(Se ricordo bene, a un certo punto questo era l'unico modo per chiamare i costruttori genitori in PHP.)

D

(DMD32 D Compiler v2.067.1, build di Windows)

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

Nota che questo invierà il compilatore in un ciclo infinito e lo arresterà in modo anomalo.

Errore: memoria insufficiente

La lumaca meccanica ha suggerito che le funzioni di programmazione in fase di compilazione in D potrebbero essere abusate per questo scopo, ma la soluzione è forse più semplice del tipo di tecniche che aveva in mente.

Per coloro che non hanno familiarità con i "mixin di stringhe", è una funzione macro abbastanza semplice. Quando il compilatore incontra mixin("asdf"), lo sostituisce con il contenuto della stringa asdfe prova a compilarlo di nuovo.

La soluzione sopra sarà espansa come:

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

Quindi, a meno che il compilatore non tenti di rilevare questo caso di espansione nello stesso caso, entrerà in un ciclo infinito di espansione.

Perl

Questo definisce l'overloading dell'operatore in fase di compilazione ed esegue il codice in fase di compilazione che somma le istanze della classe.

(a proposito, la ricorsione normalmente infinita consumerebbe tutta la memoria, ma con un sovraccarico, si blocca e basta)

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

Produzione:

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

Simplex v.0.5 , 2 byte

Peccato che questo non sia un codice-golf :

2Q

Lasciatemi spiegare. Dai documenti:

[ Q] Aggiunge il codice sorgente del programma al programma esterno, dall'inizio (esclusi i caratteri!, Se il byte corrente non è zero) Se il byte è 2, duplica anche il comando corrente.

Così:

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

Il programma esterno è una piccola caratteristica ordinata in Simplex: viene valutato alla fine del programma. Quindi, se teniamo traccia ...:

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

Alla fine, la memoria si esaurirà e il mondo finirà.

clang ++

Mi sono appena imbattuto in questo divertente bug.

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

L'obiettivo è tradurre Brainfuck in C, usando la meta-programmazione di template per svolgere gran parte del lavoro. Questo codice funziona per i programmi Brainfuck più piccoli, come Hello World, ma quando ho provato a eseguirlo con 99 bottiglie ...

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

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

Si compilerà correttamente in GCC (dopo circa 2 minuti), ma il collegamento causa un altro 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

Ops.

Smalltalk (dialetto Squeak, versione 4.x)

Molto semplice, basta valutare questo o accettare un metodo con questo letterale

1.0e99999999999999999999

Proverà a valutare la potenza di 10 nell'aritmetica dei numeri interi grandi, solo per arrotondare correttamente inf Tsss;)

Modifica: quanti 9 sono necessari?

Poiché 2 ^ 10 è 1024, circa 10 ^ 3, possiamo approssimare approssimativamente 10 ^ n di 2 ^ (10 * n / 3). Ciò significa che 10 ^ n richiede 10 * n / 3 bit per essere rappresentato in binario. Vorremmo che 10 ^ n non fosse rappresentabile.

Supponendo che i puntatori a 32 bit per la memoria degli oggetti, sappiamo che non possiamo indirizzare più di 2 ^ 32 byte, ovvero 2 ^ 35 bit. Quindi invertiamo il problema: 2 ^ 35 è circa 32 * 2 ^ 30, 32 * 10 ^ 9. Ciò richiede circa 11 cifre decimali, quindi con undici 9, siamo sicuri di generare un errore su Squeak a 32 bit. In 64 bit sarebbe ventuno 9.

Possiamo anche esaurire la memoria con meno 9 secondi, l'intero spazio indirizzabile non è necessariamente disponibile, ma è mortalmente lento da testare, Squeak VM non è ottimizzato per un'aritmetica così grande a differenza di GMP.

Questo è il mio metodo originale e conciso per bloccare GolfScript:

{1.}do

Ciò che fa è impostare un ciclo per sempre che continua a spingere 1 nello stack fino a quando la memoria si esaurisce.

In C / C ++, credo che questo pezzo di codice originale andrebbe in crash il compilatore:

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

Ciò renderebbe il compilatore bloccato raddoppiando la quantità di a e trasformandoli in b e viceversa, quindi il compilatore si esaurirebbe presto della memoria e si arresterebbe in modo anomalo.

Un altro è per batch su Windows, se conta completamente il blocco del computer piuttosto che solo lo script batch stesso. È necessario digitare quanto segue:

:a
start %0
goto a

Questo entra in un ciclo infinito di copie di se stesso, che ne fanno copie e così via. Questo molto probabilmente alla fine si bloccherebbe il tuo computer se eseguissi questo piccolo bit di codice.

Un'ultima è una bomba VBS. È un'altra bomba, come l'ultima, ma apre invece una quantità infinita di finestre di dialogo.

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

Questo crea continuamente una copia di se stesso e apre una finestra di messaggio in un ciclo infinito, cosa che fanno anche i cloni. Non è consigliabile eseguire questi ultimi due programmi, poiché possono bloccare il computer e causare l'avvio forzato del computer.

Nota che mi sono inventato tutti questi programmi.

Lisp comune, 8 byte

Più breve dell'altra risposta Common Lisp :-)

#.(loop)

Ripeti durante la lettura del modulo.

Lo standard Common Lisp non fa menzione di un modo portatile per farlo arrestare, quindi immagino che dobbiamo avere un modo definito dall'implementazione. Ancora 8 byte:

#.(quit) ; ccl

... o,

#.(exit) ; sbcl

Quando chiami (compile-file "crash.lisp"), gli ambienti si "schiantano" misteriosamente.

Scherzi a parte, sto ancora cercando di trovare un modo per bloccare veramente l'ambiente (e tra poco), ma è davvero difficile. Tutto quello che ottengo è una bella interazione con il debugger.

x86 asm

"nasm -v" restituisce "NASM versione 2.11.08 compilata il 21 febbraio 2015" (la eseguo con win7)

Finora l'assemblatore ha funzionato per 1:12:27 su un i7, saturando totalmente uno dei core. Il file di output è a 0 byte, il consumo di memoria è stato stabile a 1.004K - sembra sicuro di aver battuto il nasm, piuttosto che dargli un compito davvero molto lungo. :)

La chiave del trucco è il valore di ripetizione nella macro - 0xFFFFFFFF. Tuttavia, non ho abbastanza familiarità con gli interni di Nasm per sapere perché esattamente sta soffocando in questo. Mi aspettavo di ottenere un output di ~ 16 GB un'ora fa.

%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: appena verificato il task manager, Nasm è in esecuzione per 7:40:41 e la memoria è ora fino a 1.016K

Assemblatore di GNU, che genera enormi file di output

Questa macro tenta di riempire il file di output con garbage (in genere byte nulli) fino a raggiungere un limite di 4 GB, aggiunge un int per superare quel limite e si chiama ricorsivamente per continuare a riempire l'output con 4 GB di garbage. Questo riempirà il tuo disco rigido fino a quando non sarà pieno, a quel punto è probabile che l'assemblatore si blocchi.

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

Si noti che la ricorsione infinita non può essere utilizzata, poiché l'assemblatore rileverà quel caso speciale e smetterà di espandere la macro.

La compilazione può essere eseguita con la as -o crash.out crash.smaggior parte delle distribuzioni Linux.

Lisp comune, 29 byte

Implementazione: Clozure CL

ATTENZIONE: fai attenzione quando esegui questo codice, potrebbe uccidere i processi che non vuoi!

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

Questo esegue il comando shell pkill clal momento della compilazione, che ucciderà il processo Lisp durante la compilazione. Tecnicamente non è un crash, ma ha lo stesso effetto.

Esempio di utilizzo:

$ 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

Questo non funziona più, ma a un certo punto, questo codice:

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;

Ciò darebbe un grosso errore:

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

ERRORE DI SISTEMA bind_expression 'raised Not_found [BUG] Compilazione 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 "non riuscito Errore 1 in flx: [strerror_r] Impossibile trovare il testo per l'errore numero 1

Il problema era qui:

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

letmi aspettavo che un'espressione la seguisse, ma ho messo una dichiarazione invece. Quindi il compilatore ha dato di matto un po '.

Maggiori informazioni su https://groups.google.com/forum/m/#!topic/felix-language/J3Hs4j6E0gM .

JavaScript

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

Questo lo invia in un ciclo infinito. Ho usato il compilatore Codecademy JS e si è bloccato il mio browser.

Javascript

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

Questo blocca i browser Web in modo davvero efficace. UTILIZZARE A PROPRIO RISCHIO!!!

Hassio

File1.has:

use "File2.has";

File2.has:

use "File1.has";

Questo fa sì che Hassium si carichi e inizi a compilare File2.has, che gli dice di caricare File1.has, che gli fa caricare File2.has e così via.

LOLCODE 1.2, LOLCODE Common Interpreter / Compiler (lci)

So che questo non è code-golf ma è comunque estremamente breve.

OBTW

Ciò causa il segnale 11:

Segmentation fault (core dumped)

Perché? HAI1.2indica l'inizio del programma e OBTWavvia un commento su più righe. Ma il compilatore si aspetta che KTHXBYEa chiuda il HAI, e TLDRa chiuda il commento su più righe.

Nota che funzionerà comunque per causare segfault con qualcosa di diverso da TLDRdopo OBTW.

(Secondo gli standard di Wikipedia , LOLCODE è solo un Weirdlang, in realtà non esoterico.)
Puoi prendere l'interprete da git / justinmeza / lci .