Como programador, ciertamente conoce el error de un desbordamiento de pila debido a una recurrencia obvia. Pero ciertamente hay muchas formas extrañas e inusuales de hacer que su idioma favorito escupe ese error.

Objetivos:

1. Debe provocar un desbordamiento de pila que sea claramente visible en la salida de error.
2. No se permite usar una recurrencia obvia.

Ejemplos de programas inválidos:

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

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

Las formas más creativas son las mejores, ya que este es un concurso de popularidad . Es decir, evite respuestas obvias aburridas como esta:

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

Aunque acepté una respuesta ahora, agregar más respuestas todavía está bien :)

Pitón

import sys
sys.setrecursionlimit(1)

Esto hará que el intérprete falle inmediatamente:

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

En lugar de usar la recursividad, simplemente reduce la pila para que se desborde inmediatamente.

Pitón

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

C / Linux 32bit

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

Funciona sobrescribiendo la dirección de retorno, por lo que gvuelve al punto mainantes de llamar f. Funcionará para cualquier plataforma donde las direcciones de retorno estén en la pila, pero puede requerir ajustes.

Por supuesto, escribir fuera de una matriz es un comportamiento indefinido , y no tiene garantía de que cause un desbordamiento de la pila en lugar de, por ejemplo, pintar el bigote de azul. Los detalles de la plataforma, el compilador y los indicadores de compilación pueden marcar una gran diferencia.

JavaScript / DOM

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

    title = 'Kill me!';
}

Si quieres matar tu navegador, prueba eso en la consola.

Java

Vi algo como esto en algún lugar por aquí:

Editar: Encontrado donde lo vi: la respuesta de Joe K al programa más corto que arroja StackOverflow Error

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

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

Eso puede confundir a algunos principiantes de Java. Simplemente oculta la llamada recursiva. val + thisse convierte en val + this.toString()porque vales una cadena.

Véalo correr aquí: http://ideone.com/Z0sXiD

C

Muy fácil:

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

Desbordamiento de pila no recursivo en C

La convención de llamada no coincide.

typedef void __stdcall (* ptr) (int);

void __cdecl hello (int x) { }

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

Compilar con gcc -O0.

__cdecllas funciones esperan que la persona que llama limpie la pila, y __stdcallespera que la persona que llama lo haga, por lo que al llamar a través del puntero de la función de conversión de texto, la limpieza nunca se realiza: mainempuja el parámetro a la pila para cada llamada, pero nada aparece y finalmente la pila se llena

JavaScript

window.toString = String.toLocaleString;
+this;

Estaba frustrado por el hecho de que Java 7 y Java 8 son inmunes a mi código maligno en mi respuesta anterior . Entonces decidí que era necesario un parche para eso.

¡Éxito! Hice printStackTrace()tirar a StackOverflowError. printStackTrace()se usa comúnmente para depurar y registrar y nadie sospecha razonablemente que podría ser peligroso. No es difícil ver que se puede abusar de este código para crear algunos problemas de seguridad graves:

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

Algunas personas pueden pensar que esta es una recurrencia obvia. No lo es. El EvilExceptionconstructor no llama al getCause()método, por lo que, después de todo, esa excepción se puede lanzar de manera segura. Llamar al getCause()método no dará como resultado StackOverflowErrortampoco. La recursión está dentro del printStackTrace()comportamiento normalmente insospechado de JDK y de cualquier biblioteca de terceros para la depuración y el registro que se utilizan para inspeccionar la excepción. Además, es probable que el lugar donde se produce la excepción esté muy lejos del lugar donde se maneja.

De todos modos, aquí hay un código que arroja un StackOverflowErrory no contiene llamadas a métodos recursivos después de todo. Lo que StackOverflowErrorocurre fuera del mainmétodo, en JDK's 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"

Ensamblaje 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

Revelación:

Olvidando regresar de printHello, entonces saltamos directamente a _start nuevamente.

C ++ en tiempo de compilación

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

template <>
struct S<0> {};

template
struct S<-1>;

$ g ++ -c test.cc -ftemplate-depth = 40000
g ++: error interno del compilador: falla de segmentación (programa cc1plus)
Por favor envíe un informe de error completo,
con fuente preprocesada si corresponde.
Consulte para obtener instrucciones.

No hay recurrencia en este archivo fuente, ninguna de las clases se tiene como clase base, ni siquiera indirectamente. (En C ++, en una clase de plantilla como esta, S<1>y S<2>son clases completamente distintas.) El error de segmentación se debe al desbordamiento de la pila después de la recursión en el compilador.

Bash (alerta de peligro)

while true
do 
  mkdir x
  cd x
done

Estrictamente hablando, eso no apilará directamente el desbordamiento, sino que generará lo que se puede etiquetar como " una situación persistente de generación de apilamiento por flujo ": cuando ejecuta esto hasta que su disco esté lleno y desea eliminar el desorden con "rm -rf x ", ese es golpeado.

Sin embargo, no sucede en todos los sistemas. Algunos son más robustos que otros.

Gran peligro ADVERTENCIA:

algunos sistemas manejan esto muy mal y es posible que tenga dificultades para limpiar (porque "rm -rf" en sí mismo se encontrará con un problema de recusión). Puede que tenga que escribir un script similar para la limpieza.

Mejor intente esto en una VM virtual si no está seguro.

PD: lo mismo se aplica, por supuesto, si se programa o se realiza en un script por lotes.
PPS: puede ser interesante recibir un comentario de usted, cómo se comporta su sistema particular ...

Java

Una buena de Java Puzzlers . ¿Qué imprime?

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

Realmente falla con un StackOverflowError.

La excepción en el constructor es solo un arenque rojo. Esto es lo que el libro tiene que decir al respecto:

Cuando invoca un constructor, los inicializadores de variable de instancia se ejecutan antes que el cuerpo del constructor . En este caso, el inicializador de la variable internalInstanceinvoca al constructor de forma recursiva. Ese constructor, a su vez, inicializa su propio internalInstancecampo invocando nuevamente al constructor Renuente y así sucesivamente, hasta el infinito. Estas invocaciones recursivas provocan que StackOverflowErrorel cuerpo del constructor tenga la oportunidad de ejecutarse. Debido a que StackOverflowErrores un subtipo en Errorlugar de Exception, la cláusula catch mainno lo atrapa.

Látex

\end\end

La pila de entrada se desborda porque \endse expande repetidamente en un bucle infinito, como se explica aquí .

TeX falla con una TeX capacity exceeded, sorry [input stack size=5000]o similar.

BF

Eventualmente desbordará la pila, solo depende de cuánto tiempo el intérprete hace la pila ...

+[>+]

C #, en tiempo de compilación

Hay varias formas de hacer que el compilador de Microsoft C # explote su pila; cada vez que vea un error de "expresión es demasiado complejo para compilar" desde el compilador de C #, es casi seguro que la pila ha explotado.

El analizador es un descenso recursivo, por lo que cualquier estructura de lenguaje suficientemente anidada volará la pila:

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

El analizador de expresiones es bastante inteligente para eliminar las recursiones en el lado que comúnmente se recurre. Generalmente:

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

que construye un árbol de análisis enormemente profundo, no volará la pila. Pero si obligas a que ocurra la recursión en el otro lado:

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

entonces la pila se puede volar.

Estos tienen la propiedad poco elegante de que el programa es muy grande. También es posible hacer que el analizador semántico entre recurrencias ilimitadas con un pequeño programa porque no es lo suficientemente inteligente como para eliminar ciertos ciclos extraños en el sistema de tipos. (Roslyn podría mejorar esto).

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? 

Describo por qué este análisis entra en una recursión infinita aquí:

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

y para muchos más ejemplos interesantes deberías leer este artículo:

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

En Internet (utilizado por miles de millones de personas / día)

Redirects, HTTP status code: 301

Por ejemplo, en el sitio web de asistencia de Dell (sin ofender, lo siento, Dell):

Si elimina el TAG de soporte de la URL, se redirige infinitamente . En la siguiente URL, ###### es cualquier TAG de soporte.

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

Creo que es equivalente a un desbordamiento de pila.

PHP

Un stackoverflow hecho solo con elementos de bucle.

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

Explicación (pase el cursor para ver el spoiler):

El programa se segfault cuando el intérprete intenta recolectar basura de la $tmpmatriz (al reasignar $tmpaquí). Solo porque la matriz es demasiado profunda (referencia propia) y luego el recolector de basura termina en una recursión.

Java

Hice exactamente lo contrario: un programa que obviamente debería arrojar un error de desbordamiento de pila, pero no lo hace.

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

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

Sugerencia: el programa se ejecuta en tiempo O (2 ⁿ ), yn es el tamaño de la pila (generalmente 1024).

De Java Puzzlers # 45:

Supongamos que nuestra máquina puede ejecutar 10 ¹⁰ llamadas por segundo y generar 10 ¹⁰ excepciones por segundo, lo cual es bastante generoso para los estándares actuales. Según estos supuestos, el programa finalizará en aproximadamente 1.7 × 10 ²⁹¹ años. Para poner esto en perspectiva, la vida útil de nuestro sol se estima en 10 ¹⁰ años, por lo que es una apuesta segura que ninguno de nosotros estará presente para ver que este programa finalice. Aunque no es un bucle infinito, también podría serlo.

C#

Primera publicación, así que por favor ve con calma

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

Esto simplemente crea un seguimiento de la pila, toma el marco superior (que será nuestra última llamada Main()), obtiene el método y lo invoca.

Java

• En Java 5, printStackTrace()ingresa un bucle infinito.
• En Java 6, printStackTrace()tira StackOverflowError.
• En Java 7 y 8, se solucionó.

Lo loco es que en Java 5 y 6, no proviene del código de usuario, sucede en el código de JDK. Nadie sospecha razonablemente que printStackTrace()pueda ser peligroso ejecutar.

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: mutación de función iterativa no recursiva

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

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

No hay recursividad aquí en absoluto. fse repetirá repetidamente con más y más argumentos hasta que pueda desbordar la pila en una sola llamada de función. La console.logparte es opcional en caso de que desee ver cuántos argumentos se necesitan para hacerlo. También asegura que los motores JS inteligentes no optimicen esto.

Versión de código de golf en CoffeeScript, 28 caracteres:

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

C # con un fracaso épico

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

La forma en que falla es épica, me dejó alucinado por completo:

Es solo un fotograma de una serie de imágenes extrañas aparentemente infinitas.

Esto tiene que ser lo más raro que haya existido. ¿Alguien puede explicar? Aparentemente, la cantidad cada vez mayor de espacios utilizados para la sangría hace que aparezcan esos bloques blancos. Sucede en un Win7 Enterprise x64 con .NET 4.5.

Aún no he visto el final. Si reemplaza System.Console.Outcon System.IO.Stream.Null, muere bastante rápido.

La explicación es bastante simple. Hago una clase que tiene una sola propiedad, y siempre devuelve una nueva instancia de su tipo que contiene. Entonces es una jerarquía de objetos infinitamente profunda. Ahora necesitamos algo que intente leerlo. Ahí es donde uso el XmlSerializer, que hace exactamente eso. Y aparentemente, usa la recursividad.

golpetazo

_(){ _;};_

Si bien muchos podrían reconocer que la recursión es obvia , pero parece bonita. ¿No?

Tras la ejecución, tiene la garantía de ver:

Segmentation fault (core dumped)

Haskell

(triste pero cierto hasta al menos ghc-7.6, aunque con O1o más optimizará el problema)

main = print $ sum [1 .. 100000000]

Charla

Esto crea un nuevo método sobre la marcha, que
  crea un nuevo método sobre la marcha, que
    crea un nuevo método sobre la marcha, que
      ...
    ...
  ..
y luego se transfiere a él.

Una pequeña especia extra proviene de estresar la memoria de la pila Y la memoria del montón al mismo tiempo, al crear un nombre de método más largo y más largo, y un gran número como receptor, a medida que caemos por el agujero ... (pero la recursión nos golpea primero )

compilar en entero:

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.

luego salta, evaluando "2 downTheRabbitHole"...
... después de un tiempo, terminarás en un depurador, mostrando una RecursionException.

Luego tienes que limpiar todo el desorden (tanto SmallInteger como LargeInteger ahora tienen mucho código de país de las maravillas):

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

o de lo contrario pasar algún tiempo en el navegador, eliminando el país de las maravillas de Alice

Aquí hay algunos de la cabeza del rastro:

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

PD: se agregó el "withoutUpdatingChangesFile:" para evitar tener que limpiar el archivo de registro de cambios persistente de Smalltalk después.

PPS: gracias por el desafío: ¡pensar en algo nuevo e innovador fue divertido!

PPPS: Me gustaría señalar que algunos dialectos / versiones de Smalltalk copian los marcos de pila desbordados en el montón, por lo que en su lugar pueden quedar sin memoria.

C#

Realmente grande struct, sin recursividad, C # puro, código no inseguro.

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

como pateador, bloquea las ventanas de depuración indicando que {Cannot evaluate expression because the current thread is in a stack overflow state.}

Y la versión genérica (gracias por la sugerencia 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#

Implementación defectuosa del ==operador anulado :

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

Se podría decir que es obvio que se operator==llama a sí mismo utilizando el ==operador, pero generalmente no piensas de esa manera ==, por lo que es fácil caer en esa trampa.

Iniciando respuesta usando SnakeYAML

class A
{

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

Editar: sin golf

Depende del lector descubrir cómo funciona: P (consejo: stackoverflow.com)

Por cierto: SnakeYAML crea dinámicamente la recursividad (notará si sabe cómo detecta los campos que serializa y luego mira en Pointel código fuente)

Editar: diciendo cómo funciona ese:

SnakeYAML busca un par de getXXXy setXXXmthod con el mismo nombre XXXy el tipo de retorno del getter es el mismo que el parámetro de setter; y sorprendentemente la Pointclase tiene un Point getLocation()y void setLocation(Point P)que regresa a sí mismo; SnakeYAML no lo nota y recurre a ese capricho y StackOverflows. Descubrí eso cuando trabajaste con ellos dentro de HashMapy preguntando en stackoverflow.com sobre él.

C#

getter de propiedad implementado incorrectamente

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

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