プログラマーとして、明らかな再帰によるスタックオーバーフローのエラーを確実に知っています。しかし、間違いなく、お気に入りの言語にそのエラーを吐き出す奇妙で珍しい方法がたくさんあります。

目的：

1. エラー出力にはっきりと見えるスタックオーバーフローを引き起こす必要があります。
2. 明らかな再帰を使用することはできません。

無効なプログラムの例：

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

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

これは人気コンテストとして最も創造的な方法が最適です。つまり、次のような明白な答えを退屈させないでください。

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

今は回答を受け入れましたが、さらに回答を追加しても大丈夫です:)

Python

import sys
sys.setrecursionlimit(1)

これにより、インタープリターはすぐに失敗します。

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

再帰を使用する代わりに、スタックを縮小するだけなので、すぐにオーバーフローします。

Python

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

C / Linux 32ビット

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

戻りアドレスを上書きすることで機能します。したがってg、mainを呼び出す前にポイントに戻りますf。リターンアドレスがスタック上にあるすべてのプラットフォームで機能しますが、微調整が必​​要になる場合があります。

もちろん、配列外への書き込みは未定義の動作であり、口ひげを青く塗るなどしてスタックオーバーフローを引き起こす保証はありません。プラットフォーム、コンパイラ、およびコンパイルフラグの詳細は、大きな違いを生む可能性があります。

JavaScript / DOM

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

    title = 'Kill me!';
}

ブラウザを強制終了したい場合は、コンソールで試してみてください。

Java

この辺りをどこかで見ました：

編集：私がそれを見た場所を見つけました：StackOverflowエラーをスローする最短プログラムに対するジョーKの答え

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

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

これは、一部のJava初心者を混乱させる可能性があります。単に再帰呼び出しを非表示にします。val + thisが文字列であるval + this.toString()ためになりvalます。

ここで実行してください：http : //ideone.com/Z0sXiD

C

結構簡単：

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

Cでの非再帰的なスタックオーバーフロー

呼び出し規約の不一致。

typedef void __stdcall (* ptr) (int);

void __cdecl hello (int x) { }

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

でコンパイルしgcc -O0ます。

__cdecl関数は呼び出し側がスタックをクリーンアップする__stdcallことを期待し、呼び出し先がそれを行うことを期待するため、型キャスト関数ポインターを介して呼び出すことにより、クリーンアップは行われません- main各呼び出しでパラメーターをスタックにプッシュしますが、最終的には何もポップしませんスタックがいっぱいになります。

JavaScript

window.toString = String.toLocaleString;
+this;

以前の回答で、 Java 7とJava 8が悪のコードから免れているという事実にイライラしていました。そこで、そのためのパッチが必要であると判断しました。

成功！私はprintStackTrace()スローを作りましたStackOverflowError。printStackTrace()デバッグとロギングに一般的に使用されており、それが危険であると合理的に疑う人はいません。このコードが悪用されて深刻なセキュリティ問題が発生する可能性があることを確認するのは難しくありません。

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

一部の人々は、これは明らかな再帰だと考えるかもしれません。そうではない。EvilExceptionコンストラクタを呼び出していないgetCause()、その例外が実際にすべての後に安全にスローされる可能性があるので、この方法を。getCause()メソッドを呼び出してStackOverflowErrorも、どちらにもなりません。再帰は、JDKの通常は疑いのないprintStackTrace()動作と、例外の検査に使用されるデバッグおよびロギング用のサードパーティライブラリ内にあります。さらに、例外がスローされる場所は、処理される場所から非常に遠い可能性があります。

とにかく、ここにaをスローし、StackOverflowError再帰的なメソッド呼び出しをまったく含まないコードがあります。StackOverflowError外で発生したmainJDKの中で、方法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"

Linux x86 NASMアセンブリ

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

スポイラー：

printHelloから戻ることを忘れたため、再び_startに戻ります。

コンパイル時のC ++

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

template <>
struct S<0> {};

template
struct S<-1>;

$ g ++ -c test.cc -ftemplate-depth = 40000
g ++：内部コンパイラエラー：セグメンテーションエラー（プログラムcc1plus）
完全なバグレポートを送信してください。
必要に応じて、前処理されたソースで。
手順についてはを参照してください。

このソースファイルの再帰はありません。クラスの1つがそれ自体を基本クラスとして持っているわけではなく、間接的にもありません。（C ++では、このようなテンプレートクラスで、S<1>かつS<2>完全に別個のクラスである。）セグメンテーション違反は、コンパイラに再帰後スタックオーバーフローに起因します。

Bash（危険アラート）

while true
do 
  mkdir x
  cd x
done

厳密に言えば、直接スタックオーバーフローすることはありませんが、「永続的なスタックオーバーフローの生成状況」とラベル付けされるものを生成します。これをディスクがいっぱいになるまで実行し、「rm -rf x "、その1つがヒットします。

ただし、すべてのシステムで発生するわけではありません。他のものよりも堅牢なものもあります。

大きな危険警告：

一部のシステムはこれを非常に不適切に処理し、クリーンアップに非常に苦労する場合があります（「rm -rf」自体が異常な問題に遭遇するため）。クリーンアップするには、同様のスクリプトを作成する必要があります。

よくわからない場合は、スクラッチVMでこれを試してください。

PS：もちろん、バッチスクリプトでプログラムまたは実行された場合も同様です。
PPS：特定のシステムの動作、あなたからコメントを得るのは興味深いかもしれません...

Java

Java Puzzlersのすてきなもの。何が印刷されますか？

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

実際にはStackOverflowErrorで失敗します。

コンストラクターの例外は、ただのニシンです。これは本がそれについて言っていることです：

コンストラクターを呼び出すと、インスタンス変数初期化子がコンストラクターの本体の前で実行されます。この場合、変数の初期化子internalInstanceはコンストラクターを再帰的に呼び出します。そのコンストラクターはinternalInstance、Reluctantコンストラクターを無限に繰り返し呼び出すなどして、独自のフィールドを初期化し ます。これらの再帰呼び出しによりStackOverflowError、コンストラクター本体が実行の機会を得る前にaが発生します 。のでStackOverflowErrorのサブタイプであるErrorのではなく Exception、中のcatch句はmainそれをキャッチしません。

ラテックス

\end\end

ここで\end説明するように、無限ループで繰り返し自身を展開するため、入力スタックがオーバーフローします。

TeXは、a TeX capacity exceeded, sorry [input stack size=5000]または同様のもので失敗します。

BF

最終的にスタックをオーバーフローさせます。インタプリタがスタックを作成する時間に依存します...

+[>+]

コンパイル時のC＃

Microsoft C＃コンパイラにスタックを破壊させる方法はいくつかあります。C＃コンパイラから「式が複雑すぎてコンパイルできない」というエラーが表示されるときはいつでも、スタックが吹き飛ばされたことがほぼ確実です。

パーサーは再帰下降なので、十分に深くネストされた言語構造はスタックを爆破します。

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

式パーサーは、一般的に再帰される側の再帰を排除することについてかなり賢明です。通常：

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

非常に深い解析ツリーを構築し、スタックを爆破しません。ただし、反対側で再帰を強制する場合：

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

その後、スタックをブローできます。

これらには、プログラムが非常に大きいというエレガントな特性があります。型システム内の特定の奇数サイクルを削除するのに十分にスマートではないため、セマンティックアナライザーを小さなプログラムで無制限に再帰させることもできます。（Roslynはこれを改善するかもしれません。）

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? 

ここで、この分析が無限再帰になる理由を説明します。

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

さらに多くの興味深い例については、このペーパーをお読みください。

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

インターネット （1日あたり10億人が使用）

Redirects, HTTP status code: 301

たとえば、DellサポートWebサイト（違反なし、ごめんなさいDell）：

URLからサポートTAGを削除すると、 無限リダイレクトになります。次のURLで、######はサポートTAGです。

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

スタックオーバーフローと同等だと思います。

PHP

ループ要素のみで行われるスタックオーバーフロー。

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

説明（スポイラーを見ること）：

インタープリターが$tmp配列をガベージコレクションしようとすると（$tmpここで再割り当てするとき）、プログラムはセグメンテーション違反を起こします。配列が深すぎる（自己参照）ために、ガベージコレクターが再帰的になります。

Java

私はまったく逆のことを行いました。明らかに、スタックオーバーフローエラーをスローするはずのプログラムですが、そうではありません。

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

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

ヒント：プログラムはO（2 ⁿ）時間で実行され、nはスタックのサイズ（通常は1024）です。

以下からのJavaのpuzzlers＃45：

私たちのマシンが毎秒10 ¹⁰コールを実行し、毎秒10 ^10の例外を生成できると仮定しましょう。これは現在の標準ではかなり寛大です。これらの仮定の下では、プログラムは約1.7×10 ²⁹¹年で終了します。これを視野に入れると、太陽の寿命は10 ¹⁰年と推定されるため、このプログラムが終了するのを見るために誰もいないというのは安全な賭けです。それは無限ループではありませんが、そうかもしれません。

C＃

最初の投稿ですので、私に簡単に行ってください。

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

これは単にスタックトレースを作成し、一番上のフレーム（最後の呼び出しMain()）を取得し、メソッドを取得して呼び出します。

Java

• Java 5ではprintStackTrace()、無限ループに入ります。
• Java 6では、をprintStackTrace()スローしStackOverflowErrorます。
• Java 7および8では修正されました。

クレイジーなことは、Java 5および6ではユーザーコードからではなく、JDKのコードで発生することです。printStackTrace()実行するのが危険な合理的な容疑者はいません。

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：非再帰的な反復関数の突然変異

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

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

ここには再帰はまったくありません。単一の関数呼び出しでfスタックをオーバーフローできるようになるまで、より多くの引数で繰り返しカリーされます。このconsole.log部分は、実行に必要な引数の数を確認する場合のオプションです。また、巧妙なJSエンジンがこれを最適化しないようにします。

CoffeeScriptのコードゴルフバージョン、28文字：

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

エピックが失敗したC＃

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

それが失敗する方法は壮大です、それは私の心を完全に吹き飛ばしました：

これは、一見無限に見える奇妙な一連の画像のほんの1フレームです。

これは、これまでで最も奇妙なことでなければなりません。誰でも説明できますか？どうやら、インデントに使用されるスペースの量が増え続けると、それらの白いブロックが表示されます。.NET 4.5を搭載したWin7 Enterprise x64で発生します。

私は実際にそれの終わりを見ていません。あなたが交換した場合System.Console.OutにSystem.IO.Stream.Null、それはかなり速く死にます。

説明はとても簡単です。単一のプロパティを持つクラスを作成します。このクラスは常に、含まれる型の新しいインスタンスを返します。したがって、これは無限に深いオブジェクト階層です。今、それを読み通そうとするものが必要です。それが私が使用する場所でXmlSerializer、まさにそれを行います。そして、明らかに、再帰を使用します。

バッシュ

_(){ _;};_

多くの人が再帰が明らかであることを認識するかもしれませんが、それはかなりのようです。番号？

実行すると、以下が表示されます。

Segmentation fault (core dumped)

ハスケル

（悲しいが、少なくともghc-7.6、O1それ以上であれば問題を最適化するまでは真）

main = print $ sum [1 .. 100000000]

Smalltalk

これにより、新しいメソッドがオンザフライで
  作成され、新しいメソッドがオンザフライで
    作成され、新しいメソッドがオンザフライで作成され、
      ...
    ...
  ..
に転送されます。

余分な小さなスパイスは、スタックメモリとヒープメモリに同時にストレスをかけることによってもたらされます。これは、より長いメソッド名とより長いメソッド名の両方を作成し、レシーバーとして膨大な数を作成することにより、穴に落ちたときに...（ただし、再帰が最初にヒットします）。

整数でコンパイル：

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.

次に、評価してジャンプし"2 downTheRabbitHole"ます...
...しばらくすると、デバッガーに戻り、RecursionExceptionが表示されます。

次に、すべての混乱をクリーンアップする必要があります（SmallIntegerとLargeIntegerの両方に多くの不思議の国のコードがあります）。

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

または、ブラウザでしばらく時間を過ごして、アリスの不思議の国を削除します。

以下は、トレースの先頭からの抜粋です。

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：Smalltalkの永続的な変更ログファイルを後でクリーンアップする必要を避けるために、「withoutUpdatingChangesFile：」が追加されました。

PPS：挑戦してくれてありがとう：新しくて革新的な何かについて考えるのは楽しかったです！

PPPS：一部のSmalltalk方言/バージョンでは、オーバーフローするスタックフレームがヒープにコピーされるため、メモリ不足の状態に陥る可能性があることに注意してください。

C＃

本当に大きくstruct、再帰なし、純粋なC＃、安全でないコードではありません。

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

キッカーとして、デバッグウィンドウをクラッシュさせて {Cannot evaluate expression because the current thread is in a stack overflow state.}

そして、汎用バージョン（提案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＃

オーバーライドされた==演算子の実装の誤り：

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

演算子operator==を使用して自分自身を呼び出すことは明らかであると言うかもしれません==が、通常はそのように考えていない==ので、そのintoに陥りやすいです。

SnakeYAMLを使用して返信を開始する

class A
{

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

編集：ungolfed it

その仕組みを知るのは読者次第です：P（tip：stackoverflow.com）

ちなみに、再帰はSnakeYAMLによって動的に作成されます（シリアル化されたフィールドの検出方法を知っていれば、ソースコードで確認できますPoint）

編集：その仕組みを伝える：

SnakeYAMLは、一対探しgetXXXとsetXXXで同じ名前でmthod XXXとゲッターの戻り値の型は、セッターのパラメータと同じです。そして驚くべきことに、PointクラスにはがありPoint getLocation()、void setLocation(Point P)それはそれ自体を返します。SnakeYAMLはそれに気づかず、その癖とStackOverflowsを繰り返します。内部で彼らと働いて、そのHashMap上でstackoverflow.comに尋ねると、それを発見しました。

C＃

誤って実装されたプロパティゲッター

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

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