Come programmatore conosci certamente l'errore di un overflow dello stack dovuto a un'ovvia ricorsione. Ma ci sono sicuramente molti modi strani e insoliti per far sputare la tua lingua preferita a quell'errore.

obiettivi:

1. Deve causare un overflow dello stack chiaramente visibile sull'output dell'errore.
2. Non è consentito utilizzare una ricorsione evidente.

Esempi di programmi non validi:

// Invalid, direct obvious recursion.
methodA(){ methodA(); }

// Invalid, indirect, but obvious recursion.
methodA(){ methodB(); }
methodB(){ methodA(); }

I modi più creativi sono i migliori in quanto questo è un concorso di popolarità . Vale a dire, evitare noiose risposte ovvie come questa:

throw new StackOverflowError(); // Valid, but very boring and downvote-deserving.

Anche se ho accettato una risposta ora, l'aggiunta di più risposte è ancora ok :)

Pitone

import sys
sys.setrecursionlimit(1)

Ciò farà fallire immediatamente l'interprete:

$ cat test.py
import sys
sys.setrecursionlimit(1)
$ python test.py
Exception RuntimeError: 'maximum recursion depth exceeded' in <function _remove at 0x10e947b18> ignored
Exception RuntimeError: 'maximum recursion depth exceeded' in <function _remove at 0x10e8f6050> ignored
$ 

Invece di usare la ricorsione, riduce semplicemente lo stack in modo da traboccare immediatamente.

Pitone

import webbrowser
webbrowser.open("http://stackoverflow.com/")

C / Linux 32 bit

void g(void *p){
        void *a[1];
        a[2]=p-5;
}
void f(){
        void *a[1];
        g(a[2]);
}
main(){
        f();
        return 0;
}

Funziona sovrascrivendo l'indirizzo di ritorno, quindi gtorna al punto mainprima di chiamare f. Funzionerà per qualsiasi piattaforma in cui gli indirizzi di ritorno sono nello stack, ma potrebbe richiedere modifiche.

Naturalmente, scrivere al di fuori di un array è un comportamento indefinito e non hai alcuna garanzia che causerà un overflow dello stack piuttosto che, diciamo, dipingi i baffi in blu. I dettagli dei flag di piattaforma, compilatore e compilation possono fare una grande differenza.

JavaScript / DOM

with (document.body) {
    addEventListener('DOMSubtreeModified', function() {
        appendChild(firstChild);
    }, false);

    title = 'Kill me!';
}

Se vuoi uccidere il tuo browser, provalo nella console.

Giava

Ho visto qualcosa del genere da qualche parte qui intorno:

Modifica: trovato dove l'ho visto: la risposta di Joe K al programma più breve che genera l'errore StackOverflow

public class A {
    String val;
    public String toString() {
        return val + this;
    }

    public static void main(String[] args) {
        System.out.println(new A());
    }
}

Ciò può confondere alcuni principianti di Java. Nasconde semplicemente la chiamata ricorsiva. val + thisdiventa val + this.toString()perché valè una stringa.

Guardalo correre qui: http://ideone.com/Z0sXiD

C

Abbastanza semplice:

int main()
{
    int large[10000000] = {0};
    return 0;
}

Stack over non ricorsivo in C

Richiamo della mancata corrispondenza della convenzione.

typedef void __stdcall (* ptr) (int);

void __cdecl hello (int x) { }

void main () {
  ptr goodbye = (ptr)&hello;
  while (1) 
    goodbye(0);
}

Compila con gcc -O0.

__cdeclle funzioni si aspettano che il chiamante ripulisca lo stack e si __stdcallaspetta che il chiamante lo faccia, quindi chiamando il puntatore della funzione typecast, il cleanup non viene mai eseguito - maininserisce il parametro nello stack per ogni chiamata ma nulla lo apre e alla fine il riempimenti a pila.

JavaScript

window.toString = String.toLocaleString;
+this;

Ero frustrato dal fatto che java 7 e java 8 siano immuni al mio codice malvagio nella mia risposta precedente . Così ho deciso che era necessaria una patch per quello.

Successo! Ho fatto printStackTrace()lanciare a StackOverflowError. printStackTrace()viene comunemente utilizzato per il debug e la registrazione e nessuno sospetta ragionevolmente che possa essere pericoloso. Non è difficile vedere che questo codice potrebbe essere abusato per creare alcuni gravi problemi di sicurezza:

public class StillMoreEvilThanMyPreviousOne {
    public static void main(String[] args) {
        try {
            evilMethod();
        } catch (Exception e) {
            e.printStackTrace();
        }
    }

    private static void evilMethod() throws Exception {
        throw new EvilException();
    }

    public static class EvilException extends Exception {
        @Override
        public Throwable getCause() {
            return new EvilException();
        }
    }
}

Alcune persone potrebbero pensare che si tratti di una ovvia ricorsione. Non è. Il EvilExceptioncostruttore non chiama il getCause()metodo, quindi l'eccezione può effettivamente essere lanciata in modo sicuro dopo tutto. La chiamata al getCause()metodo non comporterà StackOverflowErrorneanche uno. La ricorsione è all'interno del printStackTrace()comportamento normalmente insospettato di JDK e di qualsiasi libreria di terze parti per il debug e la registrazione utilizzata per ispezionare l'eccezione. Inoltre, è probabile che il luogo in cui viene generata l'eccezione sia molto lontano dal luogo in cui viene gestita.

Ad ogni modo, ecco un codice che genera un StackOverflowErrore non contiene chiamate di metodo ricorsive dopo tutto. Il StackOverflowErroravviene al di fuori del mainmetodo, in JDK di UncaughtExceptionHandler:

public class StillMoreEvilThanMyPreviousOneVersion2 {
    public static void main(String[] args) {
        evilMethod();
    }

    private static void evilMethod() {
        throw new EvilException();
    }

    public static class EvilException extends RuntimeException {
        @Override
        public Throwable getCause() {
            return new EvilException();
        }
    }
}

Exception: java.lang.StackOverflowError thrown from the UncaughtExceptionHandler in thread "main"

Assemblaggio NASM Linux x86

section .data
    helloStr:     db 'Hello world!',10 ; Define our string
    helloStrLen:  equ $-helloStr       ; Define the length of our string

section .text
    global _start

    doExit:
        mov eax,1 ; Exit is syscall 1
        mov ebx,0 ; Exit status for success
        int 80h   ; Execute syscall

    printHello:
        mov eax,4           ; Write syscall is No. 4
        mov ebx,1           ; File descriptor 1, stdout
        mov ecx,helloStr    ; Our hello string
        mov edx,helloStrLen ; The length of our hello string
        int 80h             ; execute the syscall

    _start:
        call printHello ; Print "Hello World!" once
        call doExit     ; Exit afterwards

spoiler:

Dimentica di tornare da printHello, quindi saltiamo di nuovo a _start di nuovo.

C ++ al momento della compilazione

template <unsigned N>
struct S : S<N-1> {};

template <>
struct S<0> {};

template
struct S<-1>;

$ g ++ -c test.cc -ftemplate-depth = 40000
g ++: errore interno del compilatore: errore di segmentazione (programma cc1plus)
Invia una segnalazione di bug completa,
con sorgente preelaborata, se del caso.
Vedi per istruzioni.

Non c'è ricorsione in questo file sorgente, nessuna delle classi ha se stessa come classe base, neppure indirettamente. (In C ++, in una classe modello come questa, S<1>e S<2>sono classi completamente distinte.) L'errore di segmentazione è dovuto allo overflow dello stack dopo la ricorsione nel compilatore.

Bash (avviso di pericolo)

while true
do 
  mkdir x
  cd x
done

A rigor di termini, ciò non impilerà direttamente l'overflow, ma genera ciò che può essere etichettato come " una situazione generatrice di stack overflow persistente ": quando si esegue questo fino a quando il disco è pieno e si desidera rimuovere il disordine con "rm -rf x ", quello viene colpito.

Tuttavia, non accade su tutti i sistemi. Alcuni sono più robusti di altri.

Grande pericolo AVVERTENZA:

alcuni sistemi lo gestiscono molto male e potresti avere difficoltà a ripulire (perché "rm -rf" stesso avrà un problema di recusione). Potrebbe essere necessario scrivere uno script simile per la pulizia.

Meglio provare questo in un VM scratch se non ne sono sicuro.

PS: lo stesso vale, ovviamente, se programmato o eseguito in uno script batch.
PPS: potrebbe essere interessante ricevere un commento da te, come si comporta il tuo sistema particolare ...

Giava

Una bella di Java Puzzlers . Che cosa stampa?

public class Reluctant {
    private Reluctant internalInstance = new Reluctant();

    public Reluctant() throws Exception {
        throw new Exception("I'm not coming out");
    }

    public static void main(String[] args) {
        try {
            Reluctant b = new Reluctant();
            System.out.println("Surprise!");
        } catch (Exception ex) {
            System.out.println("I told you so");
        }
    }
}

In realtà non riesce con StackOverflowError.

L'eccezione nel costruttore è solo un'aringa rossa. Questo è ciò che il libro ha da dire al riguardo:

Quando si richiama un costruttore, gli inizializzatori di variabili di istanza vengono eseguiti prima del corpo del costruttore . In questo caso, l'inizializzatore per la variabile internalInstanceinvoca ricorsivamente il costruttore. Quel costruttore, a sua volta, inizializza il proprio internalInstancecampo invocando di nuovo il costruttore Riluttante e così via, all'infinito. Queste invocazioni ricorsive fanno sì che StackOverflowErrorprima che il corpo del costruttore abbia la possibilità di eseguire. Perché StackOverflowErrorè un sottotipo di Errorpiuttosto che Exception, la clausola catch in mainnon la cattura.

LaTeX

\end\end

Lo stack di input trabocca perché \endsi espande ripetutamente in un ciclo infinito, come spiegato qui .

TeX fallisce con un TeX capacity exceeded, sorry [input stack size=5000]o simile.

BF

Alla fine traboccerà lo stack, dipende solo da quanto l'interprete fa lo stack ...

+[>+]

C #, al momento della compilazione

Esistono diversi modi per fare in modo che il compilatore Microsoft C # esploda il suo stack; ogni volta che viene visualizzato un errore "espressione troppo complessa per la compilazione" dal compilatore C # che è quasi certamente dovuto al fatto che lo stack è saltato.

Il parser è una discesa ricorsiva, quindi tutte le strutture linguistiche sufficientemente annidate faranno impazzire:

 class C { class C { class C { ....

Il parser di espressioni è piuttosto intelligente nell'eliminare le ricorsioni sul lato che è comunemente ricorsivo. Generalmente:

x = 1 + 1 + 1 + 1 + .... + 1;

che costruisce un albero di analisi enormemente profondo, non farà esplodere la pila. Ma se si forza la ricorsione ad avvenire dall'altra parte:

x = 1 + (1 + (1 + (1 + ....+ (1 + 1))))))))))))))))))))))))))))))))))))))))))...;

quindi la pila può essere saltata.

Questi hanno la proprietà inelegante che il programma è molto grande. È anche possibile trasformare l'analizzatore semantico in ricorsioni illimitate con un piccolo programma perché non è abbastanza intelligente da rimuovere determinati cicli dispari nel sistema dei tipi. (Roslyn potrebbe migliorare questo.)

public interface IN<in U> {}
public interface IC<X> : IN<IN<IC<IC<X>>>> {}
...
IC<double> bar = whatever;
IN<IC<string>> foo = bar;  // Is this assignment legal? 

Descrivo perché questa analisi va in una ricorsione infinita qui:

http://blogs.msdn.com/b/ericlippert/archive/2008/05/07/covariance-and-contravariance-part-twelve-to-infinity-but-not-beyond.aspx

e per molti altri esempi interessanti dovresti leggere questo documento:

http://research.microsoft.com/en-us/um/people/akenn/generics/FOOL2007.pdf

Su Internet (utilizzato da miliardi di persone / giorno)

Redirects, HTTP status code: 301

Ad esempio, sul sito Web dell'assistenza Dell (senza offesa, scusa Dell):

Se si rimuove il TAG di supporto dall'URL, si passa a reindirizzamenti infiniti . Nel seguente URL, ###### è qualsiasi TAG di supporto.

http://www.dell.com/support/drivers/uk/en/ukdhs1/ServiceTag/######?s=BSD&~ck=mn

Credo che sia equivalente a un overflow dello stack.

PHP

Uno stackoverflow fatto solo con elementi di loop.

$a = array(&$a);
while (1) {
    foreach ($a as &$tmp) {
        $tmp = array($tmp, &$a);
    }
}

Spiegazione (passa con il mouse per vedere lo spoiler):

Il programma segfault quando l'interprete tenta di eseguire il garbage collection $tmpdell'array (durante la riassegnazione $tmpqui). Solo perché l'array è troppo profondo (autoreferenziazione) e quindi il Garbage Collector finisce in una ricorsione.

Giava

Ho fatto esattamente il contrario: un programma che ovviamente dovrebbe generare un errore di overflow dello stack, ma non lo fa.

public class Evil {
    public static void main(String[] args) {
        recurse();
    }

    private static void recurse() {
        try {
            recurse();
        } finally {
            recurse();
        }
    }
}

Suggerimento: il programma viene eseguito in tempo O (2 ⁿ ) e n è la dimensione dello stack (in genere 1024).

Da Java Puzzlers # 45:

Supponiamo che la nostra macchina possa eseguire 10 ¹⁰ chiamate al secondo e generare 10 ¹⁰ eccezioni al secondo, il che è abbastanza generoso dagli standard attuali. In base a questi presupposti, il programma terminerà tra circa 1,7 × 10 ²⁹¹ anni. Per mettere questo in prospettiva, la durata del nostro sole è stimata in 10 ¹⁰ anni, quindi è una scommessa sicura che nessuno di noi sarà in giro per vedere terminare questo programma. Sebbene non sia un ciclo infinito, potrebbe anche esserlo.

C #

Primo post, quindi per favore andate piano con me.

class Program
{
    static void Main()
    {
        new System.Diagnostics.StackTrace().GetFrame(0).GetMethod().Invoke(null, null);
    }
}

Questo crea semplicemente una traccia dello stack, prende il frame superiore (che sarà la nostra ultima chiamata a Main()), ottiene il metodo e lo invoca.

Giava

• In Java 5, printStackTrace()entra in un ciclo infinito.
• In Java 6, printStackTrace()genera StackOverflowError.
• In Java 7 e 8, è stato risolto.

La cosa folle è che in Java 5 e 6, non proviene dal codice utente, succede nel codice JDK. Nessuno sospetta ragionevole che printStackTrace()possa essere pericoloso da eseguire.

public class Bad {
    public static void main(String[] args) {
        try {
            evilMethod();
        } catch (Exception e) {
            e.printStackTrace();
        }
    }

    private static void evilMethod() throws Exception {
        Exception a = new Exception();
        Exception b = new Exception(a);
        a.initCause(b);
        throw a;
    }
}

JavaScript: mutazione della funzione iterativa non ricorsiva

var f = function() {
    console.log(arguments.length);
};

while (true) {
    f = f.bind(null, 1);
    f();
}

Non c'è nessuna ricorsione qui. fverrà ripetutamente scritto con sempre più argomenti fino a quando non sarà in grado di traboccare lo stack in una singola chiamata di funzione. La console.logparte è facoltativa nel caso in cui si desideri vedere quanti argomenti sono necessari per farlo. Assicura inoltre che i motori JS intelligenti non lo ottimizzino.

Versione code-golf in CoffeeScript, 28 caratteri:

f=->
do f=f.bind f,1 while 1

C # con un fallimento epico

using System.Xml.Serialization;

[XmlRoot]
public class P
{
    public P X { get { return new P(); } set { } }
    static void Main()
    {
        new XmlSerializer(typeof(P)).Serialize(System.Console.Out, new P());
    }
}

Il modo in cui fallisce è epico, mi ha sconvolto completamente:

È solo un fotogramma di una serie ininterrotta apparentemente infinita di strane immagini.

Questa deve essere la cosa più strana di sempre. Qualcuno può spiegare? Apparentemente, la quantità sempre crescente di spazi utilizzati per il rientro fa apparire quei blocchi bianchi. Succede su un Win7 Enterprise x64 con .NET 4.5.

Non ho ancora visto la fine. Se si sostituisce System.Console.Outcon System.IO.Stream.Null, muore abbastanza veloce.

La spiegazione è piuttosto semplice. Faccio una classe che ha una sola proprietà e restituisce sempre una nuova istanza del suo tipo contenente. Quindi è una gerarchia di oggetti infinitamente profonda. Ora abbiamo bisogno di qualcosa che cerchi di leggerlo. È lì che uso il XmlSerializer, che fa proprio questo. E apparentemente, usa la ricorsione.

bash

_(){ _;};_

Mentre molti potrebbero riconoscere che la ricorsione è ovvia , ma sembra carina. No?

Al momento dell'esecuzione, si è certi di vedere:

Segmentation fault (core dumped)

Haskell

(triste ma vero fino almeno ghc-7.6, sebbene con O1o più ottimizzerà il problema via)

main = print $ sum [1 .. 100000000]

Smalltalk

Questo crea un nuovo metodo al volo, che
  crea un nuovo metodo al volo, che
    crea un nuovo metodo al volo, che
      ...
    ...
  ..
e quindi trasferisce ad esso.

Una piccola spezia extra deriva dallo stress della memoria dello stack E dalla memoria dell'heap allo stesso tempo, creando sia un nome di metodo sempre più lungo, sia un numero enorme come ricevitore, mentre cadiamo nel buco ... (ma la ricorsione ci colpisce per prima ).

compilare in Intero:

downTheRabbitHole
    |name deeperName nextLevel|

    nextLevel := self * 2.
    name := thisContext selector.
    deeperName := (name , '_') asSymbol.
    Class withoutUpdatingChangesDo:[
        nextLevel class 
            compile:deeperName , (thisContext method source copyFrom:name size+1).
    ].
    Transcript show:self; showCR:' - and down the rabbit hole...'.
    "/ self halt. "/ enable for debugging
    nextLevel perform:deeperName.

poi salta, valutando "2 downTheRabbitHole"...
... dopo un po ', finirai in un debugger, mostrando una RecursionException.

Quindi devi ripulire tutto il casino (sia SmallInteger che LargeInteger ora hanno molto codice wonderland):

{SmallInteger . LargeInteger } do:[:eachInfectedClass |
    (eachInfectedClass methodDictionary keys 
        select:[:nm| nm startsWith:'downTheRabbitHole_'])
            do:[:each| eachInfectedClass removeSelector:each]

oppure trascorri un po 'di tempo nel browser, rimuovendo il paese delle meraviglie di Alice.

Eccone alcuni dalla testa della traccia:

2 - and down the rabbit hole...
4 - and down the rabbit hole...
8 - and down the rabbit hole...
16 - and down the rabbit hole...
[...]
576460752303423488 - and down the rabbit hole...
1152921504606846976 - and down the rabbit hole...
2305843009213693952 - and down the rabbit hole...
[...]
1267650600228229401496703205376 - and down the rabbit hole...
2535301200456458802993406410752 - and down the rabbit hole...
5070602400912917605986812821504 - and down the rabbit hole...
[...]
162259276829213363391578010288128 - and down the rabbit hole...
324518553658426726783156020576256 - and down the rabbit hole...
[...]
and so on...

PS: è stato aggiunto il file "withoutUpdatingChangesFile:" per evitare di dover successivamente ripulire il file di registro delle modifiche persistente di Smalltalk.

PPS: grazie per la sfida: pensare a qualcosa di nuovo e innovativo è stato divertente!

PPPS: Mi piace notare che alcuni dialetti / versioni di Smalltalk copiano i frame dello stack in eccesso nell'heap, quindi potrebbero invece verificarsi una situazione di memoria insufficiente.

C #

Davvero grande struct, nessuna ricorsione, C # puro, codice non pericoloso.

public struct Wyern
{
    double a, b, c, d, e, f, g, h, i, j, k, l, m, n, o, p, q, r, s, t, u, v, w, x, y, z;
}
public struct Godzilla
{
    Wyern a, b, c, d, e, f, g, h, i, j, k, l, m, n, o, p, q, r, s, t, u, v, w, x, y, z;
}
public struct Cyclops
{
    Godzilla a, b, c, d, e, f, g, h, i, j, k, l, m, n, o, p, q, r, s, t, u, v, w, x, y, z;
}
public struct Titan
{
    Cyclops a, b, c, d, e, f, g, h, i, j, k, l, m, n, o, p, q, r, s, t, u, v, w, x, y, z;
}
class Program
{
    static void Main(string[] args)
    {
        // An unhandled exception of type 'System.StackOverflowException' occurred in ConsoleApplication1.exe
        var A=new Titan();
        // 26×26×26×26×8 = 3655808 bytes            
        Console.WriteLine("Size={0}", Marshal.SizeOf(A));
    }
}

come kicker si blocca le finestre di debug affermando che {Cannot evaluate expression because the current thread is in a stack overflow state.}

E la versione generica (grazie per il suggerimento NPSF3000)

public struct Wyern<T>
    where T: struct
{
    T a, b, c, d, e, f, g, h, i, j, k, l, m, n, o, p, q, r, s, t, u, v, w, x, y, z;        
}


class Program
{
    static void Main(string[] args)
    {
        // An unhandled exception of type 'System.StackOverflowException' occurred in ConsoleApplication1.exe
        var A=new Wyern<Wyern<Wyern<Wyern<int>>>>();
    }
}

C #

Implementazione errata ==dell'operatore overriden :

public class MyClass
{
    public int A { get; set; }

    public static bool operator ==(MyClass obj1, MyClass obj2)
    {
        if (obj1 == null)
        {
            return obj2 == null;
        }
        else
        {
            return obj1.Equals(obj2);
        }
    }

    public static bool operator !=(MyClass obj1, MyClass obj2)
    {
        return !(obj1 == obj2);
    }

    public override bool Equals(object obj)
    {
        MyClass other = obj as MyClass;
        if (other == null)
        {
            return false;
        }
        else
        {
            return A == other.A;
        }
    }
}

Si potrebbe dire che è ovvio che si operator==chiama usando l' ==operatore, ma di solito non ci si pensa così ==, quindi è facile cadere in quella trappola.

Iniziare la risposta usando SnakeYAML

class A
{

    public static void main(String[] a)
    {
         new org.yaml.snakeyaml.Yaml().dump(new java.awt.Point());
    }
}

Modifica: non modificato

Sta al lettore scoprire come funziona: P (tip: stackoverflow.com)

A proposito: la ricorsione è fatta dinamicamente da SnakeYAML (noterai se sai come rileva i campi che serializza e guarda quindi nel Pointcodice sorgente)

Modifica: raccontando come funziona:

SnakeYAML cerca una coppia di getXXXe setXXXmthod con lo stesso nome XXXe il tipo di ritorno del getter è lo stesso del parametro del setter; e sorprendentemente la Pointclasse ha una Point getLocation()e void setLocation(Point P)che ritorna se stessa; SnakeYAML non se ne accorge e ricorre su quella stranezza e StackOverflow. L' HashMapho scoperto lavorando con loro all'interno di una e chiedendo su stackoverflow.com.

C #

getter di proprietà implementato erroneamente

class C
{
   public int P { get { return P; } }
}

static void Main()
{
   int p = new C().P;
}