Sebagai seorang programmer Anda tentu tahu kesalahan stack overflow karena rekursi yang jelas. Tetapi tentu saja ada banyak cara aneh dan tidak biasa untuk membuat bahasa favorit Anda meludahkan kesalahan itu.

Tujuan:

1. Harus menyebabkan stack overflow yang terlihat jelas pada output kesalahan.
2. Tidak diizinkan menggunakan rekursi yang jelas.

Contoh program yang tidak valid:

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

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

Cara paling kreatif adalah yang terbaik karena ini adalah kontes popularitas . Yaitu, hindari jawaban jelas yang membosankan seperti ini:

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

Meskipun saya menerima jawaban sekarang, menambahkan lebih banyak jawaban masih oke :)

Python

import sys
sys.setrecursionlimit(1)

Ini akan menyebabkan penerjemah segera gagal:

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

Alih-alih menggunakan rekursi, itu hanya menyusut tumpukan sehingga akan langsung meluap.

Python

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

Bekerja dengan menimpa alamat pengirim, Jadi gkembali ke titik mainsebelum menelepon f. Akan bekerja untuk platform apa pun di mana alamat pengirim berada di tumpukan, tetapi mungkin memerlukan penyesuaian.

Tentu saja, menulis di luar array adalah perilaku yang tidak terdefinisi , dan Anda tidak memiliki jaminan bahwa itu akan menyebabkan stack overflow daripada, katakanlah, cat biru kumis Anda. Detail platform, compiler dan flag kompilasi dapat membuat perbedaan besar.

JavaScript / DOM

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

    title = 'Kill me!';
}

Jika Anda ingin mematikan peramban, cobalah di konsol.

Jawa

Melihat sesuatu seperti ini di sekitar sini:

Sunting: Ditemukan di tempat saya melihatnya: Jawaban Joe K untuk program terpendek yang melempar Kesalahan StackOverflow

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

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

Itu bisa membingungkan beberapa pemula Java. Itu hanya menyembunyikan panggilan rekursif. val + thismenjadi val + this.toString()karena valadalah sebuah String.

Lihat dijalankan di sini: http://ideone.com/Z0sXiD

C

Cukup mudah:

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

Stack overflow non-rekursif dalam C

Ketidakcocokan konvensi panggilan.

typedef void __stdcall (* ptr) (int);

void __cdecl hello (int x) { }

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

Kompilasi dengan gcc -O0.

__cdeclfungsi mengharapkan penelepon untuk membersihkan tumpukan, dan __stdcallmengharapkan callee untuk melakukannya, jadi dengan memanggil melalui pointer fungsi typecast, pembersihan tidak pernah dilakukan - mainmendorong parameter ke tumpukan untuk setiap panggilan tetapi tidak ada yang muncul dan akhirnya tumpukan mengisi.

JavaScript

window.toString = String.toLocaleString;
+this;

Saya frustrasi dengan fakta bahwa java 7 dan java 8 kebal terhadap kode jahat saya di jawaban saya sebelumnya . Jadi saya memutuskan bahwa tambalan untuk itu perlu.

Keberhasilan! Saya membuat printStackTrace()lemparan StackOverflowError. printStackTrace()biasanya digunakan untuk debugging dan logging dan tidak ada yang mencurigai itu bisa berbahaya. Tidak sulit untuk melihat bahwa kode ini dapat disalahgunakan untuk menciptakan beberapa masalah keamanan serius:

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

Beberapa orang mungkin berpikir bahwa ini adalah rekursi yang jelas. Bukan itu. The EvilExceptionkonstruktor tidak menyebut getCause()metode, sehingga pengecualian yang benar-benar dapat dibuang dengan aman setelah semua. Memanggil getCause()metode tidak akan menghasilkan yang StackOverflowErrorbaik. Rekursi ini ada di dalam printStackTrace()perilaku JDK yang biasanya tidak terduga dan pustaka pihak ketiga apa pun untuk debugging dan logging yang digunakan untuk memeriksa pengecualian. Lebih lanjut, kemungkinan tempat pengecualian dibuang sangat jauh dari tempat penanganannya.

Lagi pula, ini adalah kode yang melempar StackOverflowErrordan tidak mengandung panggilan metode rekursif. The StackOverflowErrorterjadi di luar mainmetode, di JDK 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 Assembly

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:

Lupa untuk kembali dari printHello, jadi kami langsung menuju _start lagi.

C ++ pada waktu kompilasi

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

template <>
struct S<0> {};

template
struct S<-1>;

$ g ++ -c test.cc -ftemplate-depth = 40000
g ++: kesalahan kompiler internal: Kesalahan segmentasi (program cc1plus)
Silakan kirim laporan bug lengkap,
dengan sumber yang telah diproses jika perlu.
Lihat instruksi.

Tidak ada rekursi file sumber ini, tidak satu pun dari kelas itu sendiri sebagai kelas dasar, bahkan tidak secara tidak langsung. (Dalam C ++, dalam kelas templat seperti ini, S<1>dan S<2>merupakan kelas yang benar-benar berbeda.) Kesalahan segmentasi adalah karena stack overflow setelah rekursi dalam kompiler.

Bash (Peringatan Bahaya)

while true
do 
  mkdir x
  cd x
done

Sebenarnya, itu tidak akan secara langsung menumpuk overflow, tetapi menghasilkan apa yang mungkin diberi label sebagai " situasi menghasilkan stack-over-flow persisten ": ketika Anda menjalankan ini sampai disk Anda penuh, dan ingin menghapus kekacauan dengan "rm -rf x ", yang itu kena.

Itu tidak terjadi pada semua sistem. Beberapa lebih kuat dari yang lain.

Bahaya besar PERINGATAN:

beberapa sistem menangani hal ini dengan sangat buruk dan Anda mungkin mengalami kesulitan membersihkan (karena "rm-rf" itu sendiri akan mengalami masalah resusi). Anda mungkin harus menulis skrip yang mirip dengan pembersihan.

Lebih baik coba ini di VM awal jika tidak yakin.

PS: hal yang sama berlaku, tentu saja, jika diprogram atau dilakukan dalam skrip batch.
PPS: mungkin interresting untuk mendapatkan komentar dari Anda, bagaimana sistem khusus Anda berperilaku ...

Jawa

Yang bagus dari Java Puzzlers . Apa yang dicetak?

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

Ini sebenarnya gagal dengan StackOverflowError.

Pengecualian dalam konstruktor hanyalah herring merah. Inilah yang dikatakan buku tentangnya:

Ketika Anda memanggil konstruktor, inisialisasi variabel instan dijalankan sebelum badan konstruktor . Dalam hal ini, penginisialisasi untuk variabel internalInstancememanggil konstruktor secara rekursif. Konstruktor itu, pada gilirannya, menginisialisasi bidangnya sendiri internalInstancedengan memanggil konstruktor Reluctant lagi dan seterusnya, ad infinitum. Doa rekursif ini menyebabkan StackOverflowErrorsebelum tubuh konstruktor pernah mendapat kesempatan untuk mengeksekusi. Karena StackOverflowErrormerupakan subtipe Errordaripada Exception, klausa catch in maintidak menangkapnya.

Getah

\end\end

Tumpukan input meluap karena \endberulang kali mengembang dengan sendirinya dalam loop tak terbatas, seperti dijelaskan di sini .

TeX gagal dengan TeX capacity exceeded, sorry [input stack size=5000]atau serupa.

BF

Akhirnya akan meluap tumpukan, hanya tergantung berapa lama penerjemah membuat ...

+[>+]

C #, pada waktu kompilasi

Ada beberapa cara untuk menyebabkan kompiler Microsoft C # memuntahkan tumpukannya; setiap kali Anda melihat kesalahan "ekspresi terlalu rumit untuk dikompilasi" dari kompiler C # yang hampir pasti karena tumpukan telah meledak.

Parser adalah turunan rekursif, sehingga setiap struktur bahasa yang cukup bersarang akan meniup stack:

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

Pengurai ekspresi cukup pintar untuk menghilangkan rekursi pada sisi yang biasanya berulang. Biasanya:

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

yang membangun pohon parse yang sangat dalam, tidak akan meniup tumpukan. Tetapi jika Anda memaksa rekursi terjadi di sisi lain:

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

maka tumpukan bisa ditiup.

Ini memiliki properti tidak elegan bahwa program ini sangat besar. Dimungkinkan juga untuk membuat penganalisis semantik melakukan rekursi tak terbatas dengan program kecil karena tidak cukup pintar untuk menghilangkan siklus aneh tertentu dalam sistem tipe. (Roslyn mungkin memperbaiki ini.)

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? 

Saya menjelaskan mengapa analisis ini masuk ke rekursi tak terbatas di sini:

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

dan untuk banyak contoh menarik lainnya Anda harus membaca makalah ini:

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

Di Internet (digunakan oleh miliar orang / hari)

Redirects, HTTP status code: 301

Misalnya, di situs web dukungan Dell (jangan tersinggung, maaf Dell):

Jika Anda menghapus TAG dukungan dari URL, maka masuk ke pengalihan tak terbatas . Di URL berikut, ###### adalah TAG dukungan.

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

Saya percaya itu setara dengan stack overflow.

PHP

Alur stackover dilakukan dengan elemen pengulangan saja.

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

Penjelasan (arahkan kursor untuk melihat spoiler):

Program ini akan melakukan segmentasi ketika penerjemah mencoba untuk sampah mengumpulkan $tmparray pergi (ketika menugaskan kembali di $tmpsini). Hanya karena array terlalu dalam (referensi sendiri) dan kemudian pengumpul sampah berakhir dalam rekursi.

Jawa

Saya melakukan yang sebaliknya - sebuah program yang jelas harus membuang kesalahan stack overflow, tetapi tidak.

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

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

Petunjuk: program berjalan dalam waktu O (2 ⁿ ), dan n adalah ukuran tumpukan (biasanya 1024).

Dari Java Puzzlers # 45:

Mari kita asumsikan bahwa mesin kami dapat mengeksekusi 10 ¹⁰ panggilan per detik dan menghasilkan 10 ¹⁰ pengecualian per detik, yang cukup murah hati dengan standar saat ini. Berdasarkan asumsi ini, program ini akan berakhir sekitar 1,7 × 10 ²⁹¹ tahun. Untuk menempatkan ini dalam perspektif, umur matahari kita diperkirakan 10 ¹⁰ tahun, jadi itu adalah taruhan yang aman bahwa tidak seorang pun dari kita akan ada untuk melihat program ini berakhir. Meskipun ini bukan loop tak terbatas, mungkin juga demikian.

C #

Posting pertama, jadi tolong mudahkan saya.

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

Ini hanya membuat jejak stack, meraih frame atas (yang akan menjadi panggilan terakhir kami Main()), mendapatkan metode, dan memanggilnya.

Jawa

• Di Java 5, printStackTrace()memasuki loop tak terbatas.
• Di Jawa 6, printStackTrace()melempar StackOverflowError.
• Di Java 7 dan 8, sudah diperbaiki.

Yang gila adalah bahwa di Java 5 dan 6, itu tidak berasal dari kode pengguna, itu terjadi dalam kode JDK. Tidak ada satu pun tersangka masuk akal yang printStackTrace()bisa berbahaya untuk dieksekusi.

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: Mutasi fungsi berulang, non-rekursif

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

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

Tidak ada rekursi di sini sama sekali. fakan berulang kali dijilat dengan lebih banyak argumen hingga dapat meluap tumpukan dalam satu panggilan fungsi. Bagian console.logini opsional jika Anda ingin melihat berapa banyak argumen yang diperlukan untuk melakukannya. Ini juga memastikan bahwa mesin JS pintar tidak akan mengoptimalkan ini.

Versi kode-golf dalam CoffeeScript, 28 karakter:

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

C # dengan epik gagal

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

Cara itu gagal adalah epik, itu benar-benar mengejutkan saya:

Ini hanya satu bingkai dari serangkaian gambar aneh yang tampaknya tak terbatas.

Ini pasti hal yang paling aneh. Adakah yang bisa menjelaskan? Rupanya, semakin banyak ruang yang digunakan untuk lekukan menyebabkan blok putih itu muncul. Ini terjadi pada Win7 Enterprise x64 dengan .NET 4.5.

Saya belum benar-benar melihat akhirnya. Jika Anda ganti System.Console.Outdengan System.IO.Stream.Null, itu mati cukup cepat.

Penjelasannya cukup sederhana. Saya membuat kelas yang memiliki properti tunggal, dan selalu mengembalikan instance baru dari tipe yang berisi. Jadi itu adalah hierarki objek yang sangat jauh. Sekarang kita perlu sesuatu yang mencoba untuk membacanya. Di situlah saya menggunakan XmlSerializer, yang tidak hanya itu. Dan ternyata, ia menggunakan rekursi.

pesta

_(){ _;};_

Meskipun banyak yang mungkin menyadari bahwa rekursi sudah jelas , tetapi tampaknya cukup. Tidak?

Setelah eksekusi, Anda dijamin melihat:

Segmentation fault (core dumped)

Haskell

(sedih tapi benar sampai setidaknya ghc-7.6, meskipun dengan O1atau lebih itu akan mengoptimalkan masalah menjauh)

main = print $ sum [1 .. 100000000]

Smalltalk

Ini menciptakan metode baru dengan cepat, yang
  menciptakan metode baru dengan cepat, yang
    menciptakan metode baru dengan cepat, yang
      ...
    ...
  ..
dan kemudian mentransfernya.

Rempah-rempah kecil tambahan berasal dari menekankan memori stack dan menumpuk memori pada saat yang sama, dengan menciptakan nama metode yang lebih lama dan lebih lama, dan sejumlah besar sebagai penerima, saat kita jatuh ke lubang ... (tetapi rekursi menghantam kita lebih dulu ).

kompilasi dalam Integer:

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.

lalu lompat, dengan mengevaluasi "2 downTheRabbitHole"...
... setelah beberapa saat, Anda akan berakhir di debugger, menampilkan RecursionException.

Maka Anda harus membersihkan semua kekacauan (SmallInteger dan LargeInteger sekarang memiliki banyak kode wonderland):

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

atau menghabiskan waktu di browser, menghapus wonderland alice.

Berikut ini beberapa dari kepala jejak:

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: the "withoutUpdatingChangesFile:" ditambahkan untuk menghindari keharusan membersihkan file perubahan-log Smalltalk yang persisten sesudahnya.

PPS: terima kasih atas tantangannya: memikirkan sesuatu yang baru dan inovatif itu menyenangkan!

PPPS: Saya ingin mencatat bahwa beberapa dialek / versi Smalltalk menyalin frame stack yang meluap ke tumpukan - jadi ini mungkin malah menjadi situasi kehabisan memori.

C #

Sangat besar struct, tanpa rekursi, C # murni, bukan kode tidak aman.

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

sebagai kicker itu crash windows debug yang menyatakan itu {Cannot evaluate expression because the current thread is in a stack overflow state.}

Dan versi generik (terima kasih atas saran 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 #

Kesalahan implementasi ==operator utama:

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

Orang mungkin mengatakan itu jelas yang operator==menyebut dirinya dengan menggunakan ==operator, tetapi Anda biasanya tidak berpikir seperti itu ==, sehingga mudah untuk jatuh ke dalam perangkap itu.

Mulai balas menggunakan SnakeYAML

class A
{

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

Edit: ungolfed itu

Terserah pembaca untuk mengetahui cara kerjanya: P (tip: stackoverflow.com)

Omong-omong: rekursi dibuat secara dinamis oleh SnakeYAML (Anda akan melihat jika Anda tahu cara mendeteksi bidang yang diserialisasi dan melihatnya dalam Pointkode sumber)

Sunting: memberi tahu cara kerjanya:

SnakeYAML mencari sepasang getXXXdan setXXXmthod dengan nama yang sama untuk XXXdan mengembalikan tipe pengambil sama dengan parameter setter; dan yang mengejutkan, Pointkelas memiliki Point getLocation()dan void setLocation(Point P)yang mengembalikan sendiri; SnakeYAML tidak menyadarinya dan muncul kembali pada kekhasan dan aliran StackOver itu. Menemukan yang ketika bekerja dengan mereka di dalam HashMapdan bertanya pada stackoverflow.com di atasnya.

C #

pengambil properti yang diimplementasikan dengan salah

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

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