Como programador, você certamente conhece o erro de um estouro de pilha devido a uma recursão óbvia. Mas certamente existem muitas maneiras estranhas e incomuns de obter seu idioma favorito para cuspir esse erro.

Objetivos.

1. Deve causar um estouro de pilha claramente visível na saída de erro.
2. Não é permitido usar uma recursão óbvia.

Exemplos de programas inválidos:

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

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

As formas mais criativas são as melhores, pois este é um concurso de popularidade . Ou seja, evite respostas óbvias chatas como esta:

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

Embora eu tenha aceitado uma resposta agora, adicionar mais respostas ainda está bem :)

Pitão

import sys
sys.setrecursionlimit(1)

Isso fará com que o intérprete falhe imediatamente:

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

Em vez de usar a recursão, apenas encolhe a pilha e transborda imediatamente.

Pitão

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 substituindo o endereço de retorno. Portanto, gretorna ao ponto mainantes de chamarf . Funcionará para qualquer plataforma em que os endereços de retorno estejam na pilha, mas pode exigir ajustes.

Obviamente, escrever fora de uma matriz é um comportamento indefinido e você não tem garantia de que ela causará um estouro de pilha em vez de, por exemplo, pintar seu bigode de azul. Detalhes de sinalizadores de plataforma, compilador e compilação podem fazer uma grande diferença.

JavaScript / DOM

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

    title = 'Kill me!';
}

Se você quiser matar o seu navegador, tente isso no console.

Java

Vi algo assim em algum lugar por aqui:

Edit: Encontrado onde o vi: resposta de Joe K para o programa mais curto que lança o erro StackOverflow

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

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

Isso pode confundir alguns iniciantes em Java. Ele simplesmente oculta a chamada recursiva. val + thistorna-se val + this.toString()porqueval é uma String.

Veja aqui: http://ideone.com/Z0sXiD

C

Muito fácil:

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

Estouro de pilha não recursivo em C

Incompatibilidade de convenção de chamada.

typedef void __stdcall (* ptr) (int);

void __cdecl hello (int x) { }

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

Compile com gcc -O0.

__cdeclAs funções esperam que o chamador limpe a pilha e __stdcallespera que o receptor faça isso; portanto, chamando pelo ponteiro da função typecast, a limpeza nunca é feita - maincoloca o parâmetro na pilha para cada chamada, mas nada aparece e, finalmente, o pilha preenche.

Javascript

window.toString = String.toLocaleString;
+this;

Fiquei frustrado pelo fato de o java 7 e o java 8 serem imunes ao meu código maligno na minha resposta anterior . Então eu decidi que era necessário um patch para isso.

Sucesso! Eu fiz printStackTrace()jogar um StackOverflowError. printStackTrace()é comumente usado para depuração e registro em log e ninguém suspeita razoavelmente que isso possa ser perigoso. Não é difícil ver que esse código pode ser abusado para criar alguns problemas sérios de segurança:

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

Algumas pessoas podem pensar que esta é uma recursão óbvia. Não é. O EvilExceptionconstrutor não chama o getCause()método, para que a exceção possa realmente ser lançada com segurança, afinal. Chamar o getCause()método também não resultará em um StackOverflowError. A recursão está dentro do printStackTrace()comportamento normalmente insuspeitado do JDK e em qualquer biblioteca de terceiros para depuração e criação de log usada para inspecionar a exceção. Além disso, é provável que o local onde a exceção é lançada esteja muito longe do local em que é manipulado.

Enfim, aqui está um código que lança um StackOverflowErrore não contém nenhuma chamada de método recursivo, afinal. O que StackOverflowErroracontece fora do mainmétodo, nos 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"

Montagem NASM do 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:

Esquecendo de retornar de printHello, então pulamos direto para _start novamente.

C ++ em tempo de compilação

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

template <>
struct S<0> {};

template
struct S<-1>;

$ g ++ -c test.cc -ftemplate-depth = 40000
g ++: erro interno do compilador: falha de segmentação (programa cc1plus)
Envie um relatório completo de erros,
com fonte pré-processada, se apropriado.
Veja para instruções.

Não há recursão nesse arquivo de origem, nenhuma das classes tem ela própria como classe base, nem indiretamente. (Em C ++, em uma classe de modelo como essa S<1>e S<2>são classes completamente distintas.) A falha de segmentação ocorre devido ao estouro de pilha após recursão no compilador.

Bash (Alerta de Perigo)

while true
do 
  mkdir x
  cd x
done

Estritamente falando, isso não empilhará diretamente o estouro, mas gera o que pode ser rotulado como " uma situação persistente de geração de excesso de pilha ": quando você executa isso até o disco ficar cheio e deseja remover a bagunça com "rm -rf x ", esse é atingido.

Porém, isso não acontece em todos os sistemas. Alguns são mais robustos que outros.

Grande perigo AVISO:

alguns sistemas lidam com isso muito mal e você pode ter muita dificuldade em limpar (porque "rm -rf" pode ter um problema de recusa). Pode ser necessário escrever um script semelhante para a limpeza.

É melhor tentar isso em uma VM temporária, se não tiver certeza.

PS: o mesmo se aplica, é claro, se programado ou feito em um script em lote.
PPS: pode ser interessante receber um comentário de você, como seu sistema específico se comporta ...

Java

Um bom dos Java Puzzlers . O que é impresso?

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

Na verdade, ele falha com um StackOverflowError.

A exceção no construtor é apenas um arenque vermelho. Isto é o que o livro tem a dizer sobre isso:

Quando você invoca um construtor, os inicializadores da variável de instância são executados antes do corpo do construtor . Nesse caso, o inicializador para a variável internalInstancechama o construtor recursivamente. Esse construtor, por sua vez, inicializa seu próprio internalInstancecampo invocando o construtor Relutante novamente e assim por diante, ad infinitum. Essas invocações recursivas causam um StackOverflowErrorantes que o corpo do construtor tenha a chance de executar. Como StackOverflowErroré um subtipo, em Errorvez de Exception, a cláusula maincatch não a captura.

Látex

\end\end

A pilha de entrada transborda porque \endse expande repetidamente em um loop infinito, conforme explicado aqui .

O TeX falha com um TeX capacity exceeded, sorry [input stack size=5000]ou similar.

BF

Eventualmente, ela excederá a pilha, depende apenas de quanto tempo o intérprete faz a pilha ...

+[>+]

C #, em tempo de compilação

Existem várias maneiras de fazer com que o compilador Microsoft C # expanda sua pilha; sempre que você vir um erro "a expressão é muito complexa para compilar" no compilador C #, quase certamente porque a pilha explodiu.

O analisador é descendente recursivo, portanto, qualquer estrutura de linguagem suficientemente profundamente aninhada explodirá a pilha:

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

O analisador de expressão é bastante inteligente em eliminar recursões no lado comumente recorrente. Usualmente:

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

que constrói uma árvore de análise imensamente profunda, não explodirá a pilha. Mas se você forçar a recursão a acontecer do outro lado:

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

então a pilha pode ser explodida.

Eles têm a propriedade deselegante de que o programa é muito grande. Também é possível fazer o analisador semântico entrar em recursões ilimitadas com um programa pequeno, porque não é inteligente o suficiente para remover certos ciclos ímpares no sistema de tipos. (Roslyn pode melhorar isso.)

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? 

Descrevo por que essa análise entra em uma recursão infinita aqui:

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

e para muitos outros exemplos interessantes, você deve ler este artigo:

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

Na Internet (usada por bilhões de pessoas / dia)

Redirects, HTTP status code: 301

Por exemplo, no site de suporte da Dell (sem ofensa, desculpe Dell):

Se você remover o TAG de suporte do URL, ele será redirecionado infinitamente . No URL a seguir, ###### é qualquer TAG de suporte.

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

Eu acredito que é equivalente a um estouro de pilha.

PHP

Um stackoverflow feito apenas com elementos de loop.

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

Explicação (passe o mouse para ver o spoiler):

O programa irá falhar quando o intérprete tentar coletar a $tmpmatriz de lixo (quando for reatribuir $tmpaqui). Só porque a matriz é muito profunda (auto-referência) e, em seguida, o coletor de lixo termina em uma recursão.

Java

Fiz exatamente o oposto - um programa que obviamente deveria gerar um erro de estouro de pilha, mas não o faz.

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

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

Dica: o programa é executado em O (2 ⁿ tempo), e n é o tamanho da pilha (geralmente 1024).

De Java Puzzlers # 45:

Vamos supor que nossa máquina possa executar 10 ¹⁰ chamadas por segundo e gerar 10 ¹⁰ exceções por segundo, o que é bastante generoso pelos padrões atuais. Sob essas premissas, o programa será encerrado em cerca de 1,7 × 10 ²⁹¹ anos. Para colocar isso em perspectiva, a vida útil do nosso sol é estimada em 10 a ¹⁰ anos, por isso é uma aposta segura que nenhum de nós estará por perto para ver esse programa terminar. Embora não seja um loop infinito, pode muito bem ser.

C #

Primeiro post, por favor, vá com calma comigo.

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

Isso simplesmente cria um rastreamento de pilha, pega o quadro superior (que será nossa última chamada Main()), obtém o método e o invoca.

Java

• No Java 5, printStackTrace() insere um loop infinito.
• No Java 6, printStackTrace()lançaStackOverflowError .
• Nos Java 7 e 8, foi corrigido.

O mais louco é que, no Java 5 e 6, ele não vem do código do usuário, acontece no código do JDK. Ninguém suspeita razoável que printStackTrace()possa ser perigoso de executar.

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: mutação de função iterativa não recursiva

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

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

Não há recursão aqui. fserá repetidamente repetido com mais e mais argumentos até que possa estourar a pilha em uma única chamada de função. A console.logpeça é opcional caso você queira ver quantos argumentos são necessários para isso. Ele também garante que mecanismos JS inteligentes não otimizarão isso.

Versão Code-golf no CoffeeScript, 28 caracteres:

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

C # com uma falha épica

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

O jeito que ele falha é épico, me surpreendeu completamente:

É apenas um quadro de uma série aparentemente infinita de imagens estranhas.

Isso deve ser a coisa mais estranha de todas. Alguém pode explicar? Aparentemente, a quantidade cada vez maior de espaços usados ​​para indentação faz com que esses blocos brancos apareçam. Isso acontece em um Win7 Enterprise x64 com o .NET 4.5.

Eu ainda não vi o fim disso ainda. Se você substituir System.Console.Outcom System.IO.Stream.Null, morre muito rápido.

A explicação é bem simples. Eu faço uma classe que possui uma única propriedade e ela sempre retorna uma nova instância do seu tipo de contenção. Portanto, é uma hierarquia de objetos infinitamente profunda. Agora precisamos de algo que tente ler isso. É aí que eu uso o XmlSerializer, o que faz exatamente isso. E, aparentemente, ele usa recursão.

bater

_(){ _;};_

Enquanto muitos podem reconhecer que a recursão é óbvia , mas parece bonita. Não?

Após a execução, você tem a garantia de ver:

Segmentation fault (core dumped)

Haskell

(triste, mas verdadeiro até pelo menos ghc-7.6, embora com O1ou mais otimize o problema)

main = print $ sum [1 .. 100000000]

Conversa fiada

Isso cria um novo método em tempo real, que
  cria um novo método em tempo real, que
    cria um novo método em tempo real, que
      ...
    ...
  ..
e depois transfere para ele.

Um pouco mais de tempero vem do estresse da memória da pilha E da memória da pilha ao mesmo tempo, criando um nome de método cada vez mais longo e um grande número como receptor, quando caímos no buraco ... (mas a recursão nos atinge primeiro )

compilar em número inteiro:

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.

depois pule, avaliando "2 downTheRabbitHole"...
... depois de um tempo, você terminará em um depurador, mostrando uma RecursionException.

Então você precisa limpar toda a bagunça (o SmallInteger e o LargeInteger agora têm muito código do país das maravilhas):

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

ou então, passe algum tempo no navegador, removendo o país das maravilhas de alice.

Aqui estão alguns dos principais traços:

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: o "withoutUpdatingChangesFile:" foi adicionado para evitar a necessidade de limpar o arquivo de log de alterações persistente do Smalltalk posteriormente.

PPS: obrigado pelo desafio: pensar em algo novo e inovador foi divertido!

PPPS: Eu gosto de observar que algumas versões / dialetos do Smalltalk copiam quadros de pilha transbordantes para o heap - portanto, eles podem ter uma situação de falta de memória.

C #

Realmente grande struct, sem recursão, C # puro, código não seguro.

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 um kicker ele trava as janelas de depuração afirmando que {Cannot evaluate expression because the current thread is in a stack overflow state.}

E a versão genérica (obrigado pela sugestão 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 #

Implementação defeituosa do ==operador substituído :

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

Pode-se dizer que é óbvio que se operator==chama usando o ==operador, mas você geralmente não pensa assim ==, por isso é fácil cair nessa armadilha.

Iniciando a resposta usando o SnakeYAML

class A
{

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

Editar: ungolfed it

Cabe ao leitor descobrir como isso funciona: P (dica: stackoverflow.com)

A propósito: a recursão é feita dinamicamente pelo SnakeYAML (você notará se souber como ele detecta os campos que serializa e depois olhará Point código-fonte)

Edit: dizendo como isso funciona:

O SnakeYAML procura um par de getXXXe setXXXmthod com o mesmo nome XXXe o tipo de retorno do getter é o mesmo que o parâmetro do setter; e surpreendentemente a Pointclasse tem um Point getLocation()e void setLocation(Point P)que se retorna; O SnakeYAML não percebe e se repete nessa peculiaridade e StackOverflows. Descobriu aquele ao trabalhar com eles dentro de um HashMape perguntando sobre stackoverflow.com.

C #

getter de propriedade implementado incorretamente

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

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