Schreiben Sie einen vollkommen legalen Code in einer anständigen Sprache Ihrer Wahl, dessen Kompilierung entweder den Compiler zum Absturz bringt oder ihn in eine Endlosschleife (unendliche Kompilierungszeit) sendet.

Beschränkungen:

• Verwenden Sie eine Standardsprache, die in der realen Welt verwendet wird.
• Verwenden Sie einen gut entwickelten Standard-Compiler (keine Antworten wie "Ich habe meinen C-Compiler geschrieben, der auf alles abstürzt").
• Der Code muss in der Sprache legal sein (daher müssen Sie höchstwahrscheinlich einen Compiler oder einen Sprachfehler ausnutzen).
• Geben Sie Ihre Compilerversion und die verwendeten Optionen an, damit andere Benutzer sie replizieren können.
• Erklären Sie nach Möglichkeit, warum der Compiler abgestürzt ist.

Habe Spaß :)

Ich bin mir ziemlich sicher, dass es jetzt behoben ist, aber früher konnte man den Java-Compiler (oder Eclipse) durch Schreiben zum Absturz bringen

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

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

Tatsächlich hängt der Compiler laut dieser Seite nur und stürzt nicht ab. Trotzdem fand ich das ziemlich lustig.

Meine Lieblingslösung für 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

Für GHC 6.12.1 beides ghci Bad.hsund ghc Bad.hsEndlosschleife. GHC 7.4.1 ghc -O2 Bad.hswird bei Ausführung endlos wiederholt .

Erläuterung: omega Wird mit einer unendlichen Rekursion definiert (die einzige Möglichkeit, mit der ein beliebiger Typ belegt werden kann). Der Inliner des Compilers stellt xxeine einfache, nicht rekursive Funktion dar und versucht, sie in die Definition von einzufügen omega. Es führt zu (\x@(C x') -> x' x) (C xx). Wenn der Compiler eine Musterübereinstimmung auf einem Konstruktor sieht, versucht er, sie zu reduzieren, wird xx (C xx)erneut abgerufen und durchläuft eine Schleife. Der Trick ist, dass xxtatsächlich rekursiv ist, aber die Rekursion innerhalb des Datentyps verborgen ist.

Hinweis: Beim Schreiben des Puzzles habe ich vergessen, dass ich GHC in der Endlosschleife laufen ließ. Es hat all meinen Speicherplatz gekostet, Firefox ist abgestürzt und ich habe es kaum geschafft, es ohne Hard-Reset zu beenden.

Dies ist in jeder abhängig geschriebenen Sprache einfach . Die Überprüfung allgemeiner abhängiger Typen ist unentscheidbar, da sie möglicherweise beliebig komplexe Berechnungen erfordern (Turing-complete). Sie können einfach einen zu großen Wert in einen abhängigen Typ codieren. Dann nutzt die Typprüfung den gesamten verfügbaren Speicher und stürzt ab. In Coq gibt ReyCharles zum Beispiel anCompute 70000. , dass der Typprüfer eine riesige Peano-Zahl konstruiert und abstürzt.

In gängigeren Sprachen, die eine Art Makroerweiterung oder Metaprogrammierung unterstützen, können Sie etwas Ähnliches tun. Beispielsweise können Sie den gesamten verfügbaren Speicher in C verwenden:

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

Die Programmiersprache D ermöglicht die Ausführung von Funktionen zur Kompilierungszeit . Dies kann verwendet werden, um während der Kompilierung etwas zu berechnen, das zu groß ist, um in den Arbeitsspeicher zu passen. Ähnliches kann mit der Metaprogrammierung von C ++ - Vorlagen erreicht werden.

In XML (keine kompilierte Programmiersprache, aber ein XML-Prozessor ist analog zu einem Compiler) können expandierende Entitäten dazu führen, dass dem Prozessor der Speicher ausgeht:

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

Dies nennt man den Milliarden-Lacher-Angriff .

C #

Fand dies auf einer Stackoverflow-Frage :

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

Der Compiler stürzt schließlich ab.

Das Problem scheint mit der Typinferenz und / oder Lambda-Erzeugung in Verbindung mit der Überlastungsauflösung verbunden zu sein.

VBA

Wie wäre es, wenn Sie die IDE durch Eingeben von Code zum Absturz bringen könnten?

Versuchen Sie Folgendes in einer beliebigen Microsoft Office-Anwendung:

ALT+ F11Um zum VBA-Fenster zu gelangen, probieren Sie den folgenden Code

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

und siehe da:

Sie können einfach redim preserve v(,1 to 5)in das unmittelbare Fenster tippen , und es stürzt ab, nachdem Sie gedrückt haben ENTER!

Perl (15)

BEGIN{1while 1}

Dies erzeugt beim Kompilieren eine Endlosschleife :

Ein BEGIN-Codeblock wird so schnell wie möglich ausgeführt, dh in dem Moment, in dem er vollständig definiert ist, noch bevor der Rest der enthaltenen Datei (oder Zeichenfolge) analysiert wird.

(von perlmod )

Und deshalb kann Perl das Parsen des Codes nicht abschließen. Dies endet nicht:

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

J

Dieser segfaults den J-Interpreter (zumindest unter Linux):

15!:1[3#2

Es wird versucht, aus Speicheradresse 2 zu lesen. Interessanterweise erhalten Sie, wenn Sie es mit 0 oder 1 versuchen domain error.

TeX

\def\x{\x}\x

TeX ist eine Makro-Erweiterungssprache. Hier definieren wir die Expansion des Makros \xsein \xwieder, und dann fügen wir danach einen Aufruf \x. TeX bleibt endlos hängen und ersetzt \xdurch \x.

Planen

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

Mein Compiler Chicken hat den Fehler gemacht, Makros zur Kompilierungszeit für "Laufzeitleistung" oder so etwas zu erweitern. Also zahlte es den Preis für die Erweiterung dieses. Ich habe R5RS gelesen. Niemand sagte, Makros müssten zur Kompilierungszeit erweitert werden.

Im Wesentlichen wird das Makro zu einem Ausdruck von unendlicher Größe erweitert, der sich ständig verdoppelt. Um technisch zu sein, verdoppelt sich jede weitere Erweiterung. Das Schicksal des Compilers ist besiegelt. Zumindest auf meinem System blockiert Chicken Caps mit 2 GB für eine lange Zeit den Versuch, Müll zu sammeln, und stürzt dann ab, nachdem der Müllsammler aufgegeben hat. Es dauert jedoch eine Weile, da all die rechenintensiven hygienischen Probleme auftreten.

Zwischen Ausdrücken des Formulars wechseln

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

und

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

scheint die Rate des Speicherverbrauchs sehr, sehr dramatisch zu erhöhen im Vergleich zu:

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

Ich vermute, Chicken ist ein ziemlich robuster Compiler, der eine gründliche Analyse syntaktischer Ausdrücke vermeiden kann, wenn er damit durchkommt, aber meine endgültige Lösung zwingt den Pattern-Matcher, sich wirklich darauf einzulassen.

Common Lisp

Makros machen es einfach:

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

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

Kompilieren von compile-meAufrufen loop-forever, wodurch der Heapspeicher während der Erweiterung erschöpft wird und der Compiler abstürzt. Wenn Sie den Compiler nur auf unbestimmte Zeit hängen lassen möchten, wird dies durch die folgende Definition von erreicht loop-forever:

(defmacro loop-forever ()
  (loop))

Dies sollte mit jeder CL-Implementierung funktionieren, es sei denn, Ihre ist äußerst clever und kann einfache Endlosschleifen erkennen, aber ich bezweifle ernsthaft, dass dies der Fall ist. Ein vollständiger Schutz dagegen ist natürlich nicht möglich.

PHP 5.3.1 (Segfaults Interpreter) ( Bug 50261 , behoben in 5.3.3)

   Klasse testClass
   {
       Funktion testClass ()
       {
           echo 'Output string!';
       }
   }

   Klasse testClass2 erweitert testClass
   {
       Funktion __construct ()
       {
           call_user_func (array ('parent', '__construct'));
       }
   }

   new testClass2;

Dies war ein kleines Problem, da der obige Code in vielen Codes, mit denen ich gearbeitet habe, häufig vorkam, was dieses Problem für uns ziemlich weit verbreitet machte.

(Wenn ich mich richtig erinnere, war dies an einer Stelle die einzige Möglichkeit, übergeordnete Konstruktoren in PHP aufzurufen.)

D

(DMD32 D Compiler v2.067.1, Windows Build)

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

Beachten Sie, dass der Compiler dadurch in eine Endlosschleife gerät und abstürzt.

Fehler: zu wenig Speicher

Mechanical Snail schlug vor , Programmierfunktionen zur Kompilierungszeit in D für diesen Zweck zu missbrauchen, aber die Lösung ist vielleicht einfacher als die Art von Techniken, die er sich vorgestellt hatte.

Für diejenigen, die mit 'String Mixins' nicht vertraut sind, ist es eine ziemlich einfache Makrofunktion. Wenn der Compiler auf etwas stößt mixin("asdf"), ersetzt er es durch den Inhalt der Zeichenfolge asdfund versucht, es erneut zu kompilieren.

Die obige Lösung wird wie folgt erweitert:

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

Wenn der Compiler nicht versucht, diesen Fall zu erkennen, wird er in eine Endlosschleife der Erweiterung eintreten.

Perl

Dies definiert die Überladung des Operators zur Kompilierungszeit und führt den Code zur Kompilierungszeit aus, wodurch die Klasseninstanzen addiert werden.

(Im Übrigen würde eine normalerweise unendliche Rekursion den gesamten Speicher verschlingen, aber bei Überladung stürzt sie einfach ab.)

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

Ausgabe:

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

Simplex v.0.5 , 2 Bytes

Schade, dass dies kein Code-Golf ist :

2Q

Lassen Sie mich erklären. Aus den Dokumenten:

[ Q] Fügt dem äußeren Programm von Anfang an Programmquellcode hinzu (ohne! -Zeichen, wenn das aktuelle Byte nicht Null ist). Wenn Byte 2 ist, wird auch der aktuelle Befehl dupliziert.

Damit:

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

Das äußere Programm ist eine nette kleine Funktion in Simplex: Es wird am Ende des Programms ausgewertet. Also, wenn wir den Überblick behalten ...:

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

Irgendwann wird das Gedächtnis ausgehen und die Welt untergehen.

Clang ++

Ich bin gerade auf diesen lustigen Bug gestoßen.

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

Das Ziel ist es, Brainfuck in C zu übersetzen und dabei den Großteil der Arbeit mithilfe von Template-Metaprogrammierung zu erledigen. Dieser Code funktioniert für kleinere Brainfuck-Programme wie Hello World, aber als ich versuchte, ihn mit 99 Bottles auszuführen ...

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

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

Es wird erfolgreich in GCC kompiliert (nach ca. 2 Minuten), aber das Verknüpfen verursacht ein anderes Problem ...

/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

Hoppla.

Smalltalk (Squeak Dialekt, Version 4.x)

Sehr einfach, bewerten Sie dies einfach oder akzeptieren Sie eine Methode mit diesem Literal

1.0e99999999999999999999

Es wird versucht, die Potenz von 10 in Large Integer Arithmetik auszuwerten, nur um inf Tsss richtig zu runden;)

Bearbeiten: wieviele 9 sind nötig?

Da 2 ^ 10 1024, ungefähr 10 ^ 3 ist, können wir ungefähr 10 ^ n durch 2 ^ (10 * n / 3) approximieren. Das bedeutet, dass 10 ^ n 10 * n / 3 Bits erfordert, um binär dargestellt zu werden. Wir möchten 10 ^ n nicht darstellbar haben.

Unter der Annahme von 32-Bit-Zeigern für den Objektspeicher wissen wir, dass wir nicht mehr als 2 ^ 32 Bytes adressieren können, dh 2 ^ 35 Bits. Kehren wir also das Problem um: 2 ^ 35 ist ungefähr 32 * 2 ^ 30, 32 * 10 ^ 9. Das erfordert ungefähr 11 Dezimalstellen, sodass wir mit elf 9 sicher einen Fehler bei 32-Bit-Quietschen erzeugen werden. In 64 Bits wäre das einundzwanzig 9.

Wir können auch Speicher mit weniger als 9s auslasten, der gesamte adressierbare Speicherplatz ist nicht unbedingt verfügbar, aber es ist tödlich langsam zu testen, die Squeak VM ist im Gegensatz zu GMP nicht für eine solche Riesenarithmetik optimiert.

Dies ist meine originelle und prägnante Methode, um GolfScript zum Absturz zu bringen:

{1.}do

Dabei wird eine Endlosschleife eingerichtet, die weiterhin 1 auf den Stapel schiebt, bis der Speicher voll ist.

In C / C ++ glaube ich, dass dieser ursprüngliche Code den Compiler zum Absturz bringen würde:

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

Dies würde dazu führen, dass der Compiler stecken bleibt, wenn er die Menge von a verdoppelt und in b umwandelt und umgekehrt, sodass der Compiler ziemlich bald keinen Speicher mehr und keinen Absturz mehr hat.

Eine andere ist für Batch unter Windows, wenn der Computer vollständig eingefroren wird und nicht nur das Batch-Skript selbst zählt. Sie sollten Folgendes eingeben:

:a
start %0
goto a

Dies führt zu einer unendlichen Schleife, in der Kopien von sich selbst erstellt werden, die Kopien von sich selbst usw. erstellen. Dies würde höchstwahrscheinlich Ihren Computer zum Absturz bringen, wenn Sie dieses kleine Stück Code ausführen.

Eine letzte ist eine VBS-Bombe. Es ist eine andere Bombe, wie die letzte, aber stattdessen werden unendlich viele Dialogfelder geöffnet.

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

Dadurch wird fortlaufend eine Kopie von sich selbst erstellt und ein Meldungsfeld in einer Endlosschleife geöffnet, was auch die Klone tun. Das Ausführen der letzten beiden Programme wird nicht empfohlen, da sie Ihren Computer einfrieren und dazu führen können, dass Sie Ihren Computer schwer booten müssen.

Beachten Sie, dass ich mir all diese Programme selbst ausgedacht habe.

Common Lisp, 8 Bytes

Kürzer als die andere Common Lisp Antwort :-)

#.(loop)

Schleife beim Lesen Ihres Formulars.

Der Common Lisp-Standard erwähnt keine tragbare Methode, um einen Absturz zu verursachen. Ich denke, wir müssen eine implementierungsdefinierte Methode haben. Noch 8 Bytes:

#.(quit) ; ccl

... oder,

#.(exit) ; sbcl

Wenn Sie anrufen (compile-file "crash.lisp"), stürzen die Umgebungen auf mysteriöse Weise ab.

Scherz beiseite, ich versuche immer noch einen Weg zu finden, um die Umgebung wirklich zum Absturz zu bringen (und zwar in Kürze), aber es ist wirklich schwer. Alles was ich bekomme ist eine nette Interaktion mit dem Debugger.

x86 asm

"nasm -v" gibt "NASM-Version 2.11.08, kompiliert am 21. Februar 2015" zurück (läuft unter win7)

Der Assembler lief bisher 1:12:27 auf einem i7 und hat einen der Kerne vollständig ausgelastet. Die Ausgabedatei hat eine Größe von 0 Bytes, der Speicherverbrauch lag stabil bei 1.004 KB. Man kann mit Sicherheit sagen, dass ich mich überfordert habe, anstatt nur eine wirklich sehr lange Aufgabe zu erledigen. :)

Der Schlüssel zum Trick ist der Wiederholungswert im Makro - 0xFFFFFFFF. Allerdings kenne ich mich mit den Interna von Nasm nicht gut genug aus, um zu wissen, warum es genau daran erstickt. Ich habe vor einer Stunde mit einer Ausgabe von ~ 16 GB gerechnet.

%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

BEARBEITEN: Habe gerade den Task-Manager überprüft, Nasm wurde 7:40:41 ausgeführt und der Speicher ist jetzt auf 1.016 KByte angewachsen

Gnu Assembler, erzeugen riesig Ausgabedateien erzeugt

Dieses Makro versucht, die Ausgabedatei mit Müll zu füllen (normalerweise null Byte), bis eine Grenze von 4 GB erreicht ist, fügt ein int hinzu, um diese Grenze zu überschreiten, und ruft sich rekursiv auf, um die Ausgabe mit 4 GB Müllbrocken zu füllen. Dadurch wird Ihre Festplatte gefüllt, bis sie voll ist. An diesem Punkt stürzt der Assembler wahrscheinlich ab.

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

Beachten Sie, dass die unendliche Rekursion nicht verwendet werden kann, da der Assembler diesen Sonderfall abfängt und das Makro nicht mehr erweitert.

Die Kompilierung kann mit den as -o crash.out crash.smeisten Linux-Distributionen durchgeführt werden.

Common Lisp, 29 Bytes

Implementierung: Clozure CL

WARNUNG: Seien Sie vorsichtig, wenn Sie diesen Code ausführen, da er möglicherweise Prozesse abbricht, die Sie nicht möchten!

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

Dadurch wird der Shell-Befehl ausgeführt pkill cl zur Kompilierungszeit ausgeführt, wodurch der Lisp-Prozess, der die Kompilierung durchführt, abgebrochen wird. Technisch gesehen kein Absturz, aber es hat den gleichen Effekt.

Anwendungsbeispiel:

$ 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

Das funktioniert nicht mehr, aber irgendwann dieser 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;

Dies würde einen großen Fehler ergeben:

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

SYSTEMFEHLER bind_expression 'raised Not_found [BUG] Felix-Kompilierung "/ media / ryan / stuff / felix / build / release / host / bin / flxg" "-q" "--optimise" "--inline = 100" "- Ausgabeverzeichnis = / 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 "ist fehlgeschlagen Fehler 1 in flx: [strerror_r] Text für Fehlernummer 1 konnte nicht gefunden werden

Das Problem war hier:

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

letIch habe erwartet, dass ein Ausdruck darauf folgt, aber ich habe stattdessen eine Aussage gemacht. Also ist der Compiler ein bisschen ausgeflippt.

Weitere Informationen finden Sie unter https://groups.google.com/forum/m/#!topic/felix-language/J3Hs4j6E0gM .

JavaScript

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

Dies schickt es in eine Endlosschleife. Ich habe den Codecademy JS-Compiler verwendet und mein Browser ist abgestürzt.

Javascript

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

Dieser stürzt Webbrowser in einer sehr effektiven Weise ab. BENUTZUNG AUF EIGENE GEFAHR!!!

Hassium

File1.has:

use "File2.has";

File2.has:

use "File1.has";

Dies veranlasst Hassium, File2.has zu laden und mit dem Kompilieren zu beginnen, wodurch es angewiesen wird, File1.has zu laden, wodurch es File2.has lädt, und so weiter.

LOLCODE 1.2, LOLCODE Common Interpreter / Compiler (lci)

Ich weiß, dass dies kein Code-Golf ist, aber es ist trotzdem extrem kurz.

OBTW

Dies führt zu Signal 11:

Segmentation fault (core dumped)

Warum? HAI1.2bezeichnet den Start des Programms und OBTWleitet einen mehrzeiligen Kommentar ein. Aber der Compiler erwartet einer KTHXBYEdas zu schließen HAI, und eine TLDRden mehrzeiligen Kommentar zu schließen.

Beachten Sie, dass dies immer noch funktioniert, um Segfault mit etwas anderem als TLDRnachher zu verursachen OBTW.

(Nach den Standards von Wikipedia ist LOLCODE nur ein seltsamer Lang, nicht wirklich esoterisch.)
Sie können den Interpreter aus git / justinmeza / lci holen .