Ecrivez un code parfaitement légal dans un langage correct de votre choix, dont la compilation plantera le compilateur ou l'enverra dans une boucle infinie (temps de compilation infini).

Restrictions

• Utilisez un langage standard utilisé dans le monde réel.
• Utilisez un compilateur standard bien développé (pas de réponses du type "j’ai écrit mon compilateur C qui plante tout").
• Le code doit être légal dans la langue (vous devrez donc probablement exploiter un compilateur ou un bogue de langue).
• Indiquez la version de votre compilateur et les options utilisées afin que d'autres puissent la répliquer.
• Expliquez pourquoi le compilateur s'est écrasé, si possible.

S'amuser :)

Je suis presque sûr que cela a été corrigé maintenant, mais vous aviez l'habitude de faire planter le compilateur Java (ou de planter Eclipse) en écrivant

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

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

En fait, selon cette page, le compilateur se bloquera et ne plantera pas. Pourtant, je pensais que c'était assez amusant.

Ma solution préférée pour 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

Pour GHC 6.12.1 à la fois ghci Bad.hset la ghc Bad.hsboucle à l' infini. GHC 7.4.1 boucle infiniment quand ghc -O2 Bad.hsest exécuté.

Explication: omega est défini en utilisant une récursion infinie (la seule façon pour elle d’habiter n’importe quel type). L'inliner du compilateur est perçu xxcomme une fonction simple et non récursive. Il essaie donc de l'inclure dans la définition de omega. Il en résulte (\x@(C x') -> x' x) (C xx). En voyant une correspondance de motif sur un constructeur, le compilateur tente de le réduire, en récupérant xx (C xx)et en boucle. Le truc, c’est qu’il xxest effectivement récursif, mais la récursivité est masquée dans le type de données.

Remarque: lors de l'écriture du puzzle, j'avais oublié que j'avais laissé GHC s'exécuter dans la boucle infinie. Il a fallu toute ma mémoire, Firefox s'est écrasé et j'ai à peine réussi à le tuer sans réinitialisation matérielle.

Ceci est facile dans n'importe quel langage dépendant de la langue. Les types dépendants généraux de vérification de type sont indécidables car ils peuvent nécessiter des calculs arbitrairement complexes (Turing-complete). Vous pouvez simplement encoder dans un type dépendant une valeur trop grande. Ensuite, le vérificateur de type utilisera toute la mémoire disponible et plantera. Par exemple, dans Coq, ReyCharles donne l'exempleCompute 70000. , ce qui amène le vérificateur de type à construire un chiffre Peano géant et à provoquer un crash.

Dans les langages plus courants qui prennent en charge une sorte d’expansion de macro ou de métaprogrammation, vous pouvez faire quelque chose de similaire. Par exemple, vous pouvez utiliser toute la mémoire 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 }

Le langage de programmation D permet l' exécution d'une fonction au moment de la compilation . Cela peut être utilisé pour calculer quelque chose au moment de la compilation qui est trop volumineux pour tenir en mémoire. Quelque chose de similaire peut être obtenu en utilisant la métaprogrammation de modèles C ++.

En XML (pas un langage de programmation compilé, mais un processeur XML est analogue à un compilateur), les entités en développement peuvent faire que le processeur manque de mémoire:

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

C'est ce qu'on appelle l' attaque d'un milliard de rires .

C #

Trouvé ceci sur une question 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)))))));
    }
}

Le compilateur finira par planter.

Le problème semble lié à l'inférence de type et / ou à la génération lambda, combinés à la résolution de surcharge.

VBA

que diriez-vous si vous pouvez planter l'IDE en tapant du code?

Dans n'importe quelle application Microsoft Office, essayez ceci:

ALT+ F11pour accéder à la fenêtre VBA, puis essayez le code suivant

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

et voici:

Vous pouvez simplement taper redim preserve v(,1 to 5)dans la fenêtre immédiate, et il se plantera après avoir appuyé sur ENTER!

Perl (15)

BEGIN{1while 1}

Cela crée une boucle infinie au moment de la compilation :

Un bloc de code BEGIN est exécuté dès que possible, c'est-à-dire au moment où il est complètement défini, avant même que le reste du fichier contenant (ou de la chaîne) ne soit analysé.

(de perlmod )

Et c'est pourquoi Perl n'est pas en mesure de terminer l'analyse du code. Cela ne se termine pas:

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

J

Cela sépare l’interpréteur J (au moins sous Linux):

15!:1[3#2

Il essaie de lire depuis l'adresse de mémoire 2. Fait intéressant, si vous essayez avec 0 ou 1, vous obtenez domain error.

Texas

\def\x{\x}\x

TeX est un langage de macro-expansion. Nous définissons ici le développement de la macro \xcomme étant à \xnouveau, puis nous ajoutons ensuite une invocation de \x. TeX se coince sans cesse remplacer \xavec \x.

Schème

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

Mon compilateur, Chicken, a fait l'erreur d'essayer de développer des macros au moment de la compilation pour des "performances d'exécution" ou quelque chose du genre. Donc, il a payé le prix de l'expansion de celui-ci. J'ai lu R5RS. Personne n'a dit que les macros devaient être développées au moment de la compilation.

En gros, ce qui se passe, c'est que la macro se développe en une expression de taille infinie, doublant constamment de taille. Eh bien, pour être technique, doubler chaque extension. Le destin du compilateur est scellé. Au moins sur mon système, les bouchons de poulet à 2 Go bloquent longtemps en essayant de ramasser les ordures, puis se bloquent après l'abandon du ramasse-miettes. Cela prend un certain temps, cependant, à cause de la magie hygiénique coûteuse en informatique.

Basculer entre les expressions de la forme

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

et

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

semble augmenter de façon très très importante le taux de consommation de mémoire par rapport à:

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

Je soupçonne que Chicken est un compilateur assez hardi qui a certains moyens d’éviter une analyse en profondeur des expressions syntaxiques quand il peut s’en tirer, mais ma solution finale force le modélisateur de patterns à vraiment plonger dedans.

Common Lisp

Les macros rendent les choses faciles:

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

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

La compilation des compile-meappels loop-forever, qui épuise la mémoire de tas pendant son expansion et bloque le compilateur. Si vous voulez juste que le compilateur se bloque indéfiniment, alors cette définition de le loop-foreverfera:

(defmacro loop-forever ()
  (loop))

Cela devrait fonctionner avec n'importe quelle implémentation CL, à moins que le vôtre ne soit extrêmement intelligent et ne détecte de simples boucles infinies, mais je doute fort que cela se produise. Une protection complète contre cela est impossible, bien sûr.

PHP 5.3.1 (interpréteur Segfaults) ( Bug 50261 , corrigé dans 5.3.3)

   classe testClass
   {
       fonction testClass ()
       {
           echo 'Chaîne de sortie!';
       }
   }

   la classe testClass2 étend testClass
   {
       fonction __construct ()
       {
           call_user_func (array ('parent', '__construct'));
       }
   }

   new testClass2;

Celui-ci était un peu problématique, car le code ci-dessus était commun dans beaucoup de codes avec lesquels je travaillais, ce qui en fait un problème assez répandu pour nous.

(Si je me souviens bien, à un moment donné, c'était le seul moyen d'appeler les constructeurs parents en PHP.)

ré

(Compilateur DMD32 D v2.067.1, version Windows)

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

Notez que cela enverra le compilateur dans une boucle infinie et le plantera.

Erreur: mémoire insuffisante

Mechanical snail a suggéré que les fonctionnalités de programmation au moment de la compilation en D pourraient être utilisées à cette fin, mais la solution est peut-être plus simple que le type de technique qu'il avait en tête.

Pour ceux qui ne sont pas familiers avec 'string mixins', c'est une fonctionnalité macro assez simple. Lorsque le compilateur le rencontre mixin("asdf"), il le remplace par le contenu de la chaîne asdfet tente de le recompiler.

La solution ci-dessus sera étendue comme suit:

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

Donc, à moins que le compilateur ne détecte ce cas d'extension, il entrera dans une boucle d'expansion infinie.

Perl

Ceci définit la surcharge des opérateurs lors de la compilation et exécute un code lors de la compilation qui ajoute les instances de la classe.

(à propos, normalement une récursion infinie mangerait toute la mémoire, mais avec une surcharge, ça plantait)

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

Sortie:

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

Simplex v.0.5 , 2 octets

Dommage que ce ne soit pas un code-golf :

2Q

Laissez-moi expliquer. De la docs:

[ Q] Ajoute le code source du programme au programme externe, depuis le début (excluant les caractères!, Si l'octet actuel n'est pas zéro). Si l'octet est égal à 2, duplique également la commande actuelle.

Alors:

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

Le programme externe est une petite fonctionnalité intéressante dans Simplex: il est évalué à la fin du programme. Donc, si nous gardons une trace ...:

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

Finalement, la mémoire s'épuise et le monde finira.

Clang ++

Je viens de tomber sur ce bogue amusant.

#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'objectif est de traduire Brainfuck en C, en utilisant la méta-programmation de modèles pour effectuer la majeure partie du travail. Ce code fonctionne pour les programmes Brainfuck plus petits, tels que Hello World, mais lorsque j'ai essayé de l'exécuter avec 99 bouteilles ...

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

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

Il sera compilé avec succès dans GCC (après environ 2 minutes), mais le lier provoque un autre problème ...

/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

Oops.

Smalltalk (dialecte Squeak, version 4.x)

Très facile, évaluez cela ou acceptez une méthode avec ce littéral

1.0e99999999999999999999

Il essaiera d'évaluer la puissance de 10 dans l'arithmétique de grand entier, juste pour arrondir correctement inf Tsss;)

Edit: combien de 9 sont nécessaires?

Puisque 2 ^ 10 est 1024, environ 10 ^ 3, on peut approximativement 10 ^ n sur 2 ^ (10 * n / 3). Cela signifie que 10 ^ n nécessitent que 10 * n / 3 bits soient représentés en binaire. Nous aimerions avoir 10 ^ n non représentable.

En supposant des pointeurs 32 bits pour la mémoire objet, nous savons que nous ne pouvons pas adresser plus de 2 ^ 32 octets, soit 2 ^ 35 bits. Donc inversons le problème: 2 ^ 35 est environ 32 * 2 ^ 30, 32 * 10 ^ 9. Cela nécessite environ 11 chiffres décimaux, donc avec onze 9, nous sommes sûrs de générer une erreur sur 32bits Squeak. En 64 bits, ce serait vingt et un 9.

Nous pouvons également épuiser la mémoire avec moins de 9 secondes. L'ensemble de l'espace adressable n'est pas nécessairement disponible, mais il est extrêmement lent à tester, la VM Squeak n'est pas optimisée pour une telle arithmétique géante contrairement à GMP.

Voici ma méthode originale et concise pour planter GolfScript:

{1.}do

Cela permet de créer une boucle permanente qui continue d’appuyer 1 sur la pile jusqu’à épuisement de la mémoire.

En C / C ++, je pense que cet élément de code original planterait le compilateur:

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

Cela empêcherait le compilateur de doubler le nombre de a et de les transformer en b, et inversement, de sorte que le compilateur manquerait bientôt de mémoire et se planterait.

Une autre option concerne les traitements par lots sous Windows, si le blocage du traitement lui-même est pris en compte plutôt que par le traitement par lots Vous devriez taper ce qui suit:

:a
start %0
goto a

Cela entre dans une boucle infinie de faire des copies de lui-même, qui se font des copies d’elles-mêmes, etc. Cela finirait très probablement par planter votre ordinateur si vous exécutiez ce petit morceau de code.

Un dernier est une bombe de VBS. C'est une autre bombe, comme la dernière, mais elle ouvre une quantité infinie de boîtes de dialogue.

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

Cela crée continuellement une copie de lui-même et ouvre une boîte de message dans une boucle infinie, ce que font également les clones. L'exécution de ces deux derniers programmes n'est pas recommandée, car ils peuvent geler votre ordinateur et vous obliger à le démarrer dur.

Notez que je suis venu avec tous ces programmes moi-même.

Common Lisp, 8 octets

Plus courte que l'autre réponse Common Lisp :-)

#.(loop)

Bouclez en lisant votre formulaire.

La norme Common Lisp ne mentionne pas de moyen portable de le faire planter, alors je suppose que nous devons avoir un moyen défini par l'implémentation. Encore 8 octets:

#.(quit) ; ccl

... ou,

#.(exit) ; sbcl

Lorsque vous appelez (compile-file "crash.lisp"), les environnements se "plantent" mystérieusement.

Blague à part, j'essaie toujours de trouver un moyen de vraiment écraser l'environnement (et bientôt), mais c'est vraiment difficile. Tout ce que je reçois est une bonne interaction avec le débogueur.

x86 asm

"nasm -v" renvoie "NASM version 2.11.08 compilée le 21 février 2015" (je l'exécute sous win7)

L’assembleur a couru depuis 1:12:27 sur un i7, saturant totalement l’un des cœurs. Le fichier de sortie est assis à 0 octet, la consommation de mémoire est stable à 1 004 Ko - il semble raisonnable de dire que j'ai vaincu le nasme au lieu de simplement lui confier une très longue tâche. :)

La clé de l'astuce est la valeur de répétition dans la macro - 0xFFFFFFFF. Cependant, je ne connais pas suffisamment les internes de Nasm pour savoir pourquoi cela s’étouffe. Je m'attendais à obtenir une sortie de ~ 16 Go il y a une heure.

%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: Il suffit de vérifier le gestionnaire de tâches, Nasm fonctionne depuis 7h40:41 et la mémoire atteint maintenant 1 016K

Assembleur Gnu, générant d' énormes fichiers de sortie

Cette macro tente de remplir le fichier de sortie avec garbage (octets généralement nuls) jusqu'à atteindre une limite de 4 Go, ajoute un int pour dépasser cette limite et s'appelle de manière récursive pour continuer à remplir la sortie avec des morceaux de 4 Go de garbage. Cela remplira votre disque dur jusqu’à ce qu’il soit plein, ce qui provoquera le crash de l’assembleur.

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

Notez que la récursion infinie ne peut pas être utilisée, car l'assembleur interceptera ce cas particulier et cessera de développer la macro.

La compilation peut être effectuée avec la as -o crash.out crash.splupart des distributions Linux.

Common Lisp, 29 octets

Mise en oeuvre: Clozure CL

AVERTISSEMENT: soyez prudent lorsque vous exécutez ce code, il peut tuer des processus que vous ne souhaitez pas!

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

Ceci exécute la commande shell pkill cllors de la compilation, ce qui va tuer le processus Lisp qui effectue la compilation. Pas techniquement un crash, mais cela a le même effet.

Exemple d'utilisation:

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

Félix

Cela ne fonctionne plus, mais à un moment donné, ce code:

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;

Cela donnerait une grosse erreur:

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

ÉCHEC DE SYSTÈME bind_expression 'levée Not_found [BUG] Compilation de 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 / lib / grammar / grammar.files / syntax.automaton" "--import = plat / flx.flxh "" std "" /home/ryan/golf/itri/sl.flx "a échoué Erreur 1 dans flx: [strerror_r] Impossible de trouver le texte du numéro d'erreur 1

Le problème était ici:

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

letattendu une expression à la suivre, mais je mets une déclaration à la place. Donc, le compilateur a paniqué un peu.

Plus d'informations sur https://groups.google.com/forum/m/#!topic/felix-language/J3Hs4j6E0gM .

JavaScript

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

Cela l'envoie dans une boucle infinie. J'ai utilisé le compilateur Codecademy JS et mon navigateur s'est bloqué.

Javascript

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

Celui-ci bloque les navigateurs Web de manière sérieusement efficace. À UTILISER À VOS RISQUES ET PÉRILS!!!

Hassium

Fichier1.a:

use "File2.has";

Fichier2.a:

use "File1.has";

Hassium se charge alors et commence à compiler File2.has, ce qui lui dit de charger File1.has, ce qui le force à charger File2.has, etc.

LOLCODE 1.2, interpréteur / compilateur commun LOLCODE (lci)

Je sais que ce n'est pas du code-golf mais de toute façon, il est extrêmement court.

OBTW

Cela provoque le signal 11:

Segmentation fault (core dumped)

Pourquoi? HAI1.2indique le début du programme et OBTWlance un commentaire multiligne. Mais le compilateur s'attend KTHXBYEà ce HAIque TLDRles commentaires multilignes soient fermés et fermés.

Notez que cela fonctionnera toujours pour causer un segfault avec autre chose TLDRqu'après OBTW.

(Selon les normes de wikipedia , LOLCODE est juste un Weirdlang, pas réellement ésotérique.)
Vous pouvez récupérer l’interprète sur git / justinmeza / lci .