ในฐานะโปรแกรมเมอร์คุณรู้ข้อผิดพลาดของการโอเวอร์โฟลว์ของสแต็กอย่างแน่นอนเนื่องจากการเรียกซ้ำที่ชัดเจน แต่มีวิธีที่แปลกและผิดปกติหลายอย่างที่จะทำให้ภาษาโปรดของคุณแตกออกจากข้อผิดพลาดนั้น

วัตถุประสงค์:

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.

แม้ว่าฉันจะยอมรับคำตอบแล้วการเพิ่มคำตอบก็ยังไม่เป็นไร :)

หลาม

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
$ 

แทนที่จะใช้การเรียกซ้ำมันแค่ย่อขนาดสแต็กดังนั้นมันจะล้นทันที

หลาม

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

หากคุณต้องการฆ่าเบราว์เซอร์ของคุณให้ลองใช้งานในคอนโซล

ชวา

เห็นบางสิ่งเช่นนี้อยู่แถวนี้:

แก้ไข:พบที่ฉันเห็น: Joe K คำตอบของโปรแกรม Shortest ที่พ่นข้อผิดพลาด StackOverflow

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คาดว่าผู้ที่ทำมันดังนั้นโดยการเรียกผ่านตัวชี้ฟังก์ชั่น typecast การล้างจะไม่ทำ - mainดันพารามิเตอร์ลงบนสแต็กสำหรับการโทรแต่ละครั้ง แต่ไม่มีอะไรปรากฏขึ้น เติมสแต็ค

JavaScript

window.toString = String.toLocaleString;
+this;

ผมรู้สึกผิดหวังกับความจริงที่ว่า Java 7 และ Java 8 มีภูมิคุ้มกันเพื่อรหัสความชั่วร้ายของฉันในคำตอบของฉันก่อนหน้า ดังนั้นฉันจึงตัดสินใจว่าจำเป็นต้องใช้โปรแกรมปะแก้

ที่ประสบความสำเร็จ! ฉันทำโยนprintStackTrace() มักใช้สำหรับการดีบั๊กและการบันทึกและไม่มีใครสงสัยว่าอาจเป็นอันตรายได้ ไม่ยากที่จะเห็นว่ารหัสนี้อาจถูกใช้เพื่อสร้างปัญหาด้านความปลอดภัยที่ร้ายแรง:StackOverflowErrorprintStackTrace()

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ใด ๆ การเรียกซ้ำอยู่ภายในprintStackTrace()พฤติกรรมที่ไม่น่าสงสัยของ JDK และห้องสมุดบุคคลที่สามใด ๆ สำหรับการดีบักและบันทึกที่ใช้ในการตรวจสอบข้อยกเว้น นอกจากนี้อาจเป็นไปได้ว่าสถานที่ที่มีข้อยกเว้นถูกโยนไกลจากสถานที่ที่มีการจัดการ

อย่างไรก็ตามนี่คือรหัสที่จะส่ง a StackOverflowErrorและไม่มีการเรียกวิธีเรียกซ้ำหลังจากทั้งหมด StackOverflowErrorเกิดขึ้นนอกmainวิธีการใน 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

สปอยเลอร์:

ลืมที่จะกลับจาก 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)
กรุณาส่งรายงานข้อผิดพลาดแบบเต็ม
กับแหล่งที่ประมวลผลล่วงหน้าหากเหมาะสม
ดูคำแนะนำ

ไม่มีการเรียกซ้ำไฟล์ต้นฉบับนี้ไม่มีคลาสใดคลาสหนึ่งที่มีตัวเองเป็นคลาสพื้นฐานหรือแม้แต่ทางอ้อม (ใน C ++ ในเทมเพลตคลาสเช่นนี้S<1>และS<2>เป็นคลาสที่แตกต่างกันโดยสิ้นเชิง) ข้อผิดพลาดในการแบ่งเซ็กเมนต์เกิดจากการโอเวอร์โฟลว์สแต็กหลังจากเรียกซ้ำในคอมไพเลอร์

Bash (การแจ้งเตือนอันตราย)

while true
do 
  mkdir x
  cd x
done

พูดอย่างเคร่งครัดว่าจะไม่สแต็คโอเวอร์โฟลว์โดยตรง แต่สร้างสิ่งที่อาจระบุว่าเป็น " สถานการณ์การสร้างสแต็ก - โอเวอร์ - โฟล " แบบถาวร : เมื่อคุณรันสิ่งนี้จนกว่าดิสก์ของคุณจะเต็มและต้องการลบระเบียบด้วย "rm -rf x "ที่ถูกตี

มันไม่ได้เกิดขึ้นในทุกระบบ บางคนแข็งแกร่งกว่าคนอื่น

อันตรายใหญ่คำเตือน:

บางระบบการจัดการนี้มากไม่ดีและคุณอาจจะมีช่วงเวลาที่ยากมากในการทำความสะอาด (เพราะ "RM -rf" ตัวเองจะทำงานเป็นปัญหา recusion ก) คุณอาจต้องเขียนสคริปต์ที่คล้ายกันเพื่อล้างข้อมูล

ลองใช้วิธีนี้ในการลบ VM ถ้าไม่แน่ใจ

PS: เช่นเดียวกันแน่นอนถ้าโปรแกรมหรือทำในสคริปต์ชุด
PPS: อาจเป็นการรบกวนที่จะได้รับความคิดเห็นจากคุณว่าระบบของคุณทำงานอย่างไร ...

ชวา

หนึ่งที่ดีจาก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

ข้อยกเว้นในตัวสร้างเป็นเพียงปลาเฮอริ่งแดง นี่คือสิ่งที่หนังสือพูดถึง:

เมื่อคุณเรียกตัวสร้างให้เช่น initializers ตัวแปรทำงานก่อนที่ร่างของนวกรรมิก ในกรณีนี้ initializer สำหรับตัวแปรinternalInstanceจะเรียกคอนสตรัคเตอร์แบบเรียกซ้ำ ในทางกลับกันคอนสตรัคเตอร์ก็เริ่มต้นinternalInstanceฟิลด์ของตนเอง โดยเรียกใช้ตัวสร้าง Reluctant อีกครั้งและต่อไปเรื่อย ๆ ad infinitum การเรียกซ้ำแบบเรียกซ้ำเหล่านี้เป็นสาเหตุให้ StackOverflowErrorร่างกายของคอนสตรัคเตอร์ได้รับโอกาสในการดำเนินการ เนื่องจากStackOverflowErrorเป็นชนิดย่อยErrorมากกว่า Exceptionประโยคย่อยที่จับmainไม่ได้

น้ำยาง

\end\end

สแต็คการป้อนข้อมูลล้นเพราะ\endซ้ำ ๆ ขยายตัวเองในวง จำกัด ตามที่อธิบายไว้ที่นี่

TeX ล้มเหลวด้วยTeX capacity exceeded, sorry [input stack size=5000]หรือคล้ายกัน

BF

ในที่สุดจะล้นสแต็คเพียงแค่ขึ้นอยู่กับว่าล่ามทำให้กอง ...

+[>+]

C # ในเวลารวบรวม

มีหลายวิธีในการทำให้คอมไพเลอร์ Microsoft C # ระเบิดสแต็ก เมื่อใดก็ตามที่คุณเห็นข้อผิดพลาด "นิพจน์ซับซ้อนเกินกว่าจะคอมไพล์" จากคอมไพเลอร์ C # ที่เกือบจะแน่นอนเพราะสแตกได้ถูกเป่า

parser เป็นผู้สืบเชื้อสายซ้ำดังนั้นโครงสร้างภาษาที่ซ้อนกันอย่างพอเพียงจะทำให้กองซ้อน:

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

ตัวแยกวิเคราะห์นิพจน์นั้นฉลาดมากเกี่ยวกับการกำจัดการเรียกซ้ำที่ด้านข้างที่ถูกเรียกซ้ำโดยทั่วไป ปกติ:

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

ซึ่งสร้างต้นไม้ในการแยกวิเคราะห์อย่างมหาศาลจะไม่ระเบิดกอง แต่ถ้าคุณบังคับให้การเรียกซ้ำเกิดขึ้นที่อีกด้านหนึ่ง:

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

จากนั้นสแตกสามารถถูกเป่าได้

สิ่งเหล่านี้มีคุณสมบัติไม่เหมาะสมที่โปรแกรมมีขนาดใหญ่มาก นอกจากนี้ยังเป็นไปได้ที่จะทำให้ semantic analyser ไปสู่ ​​recursions ที่ไม่มีขอบเขตด้วยโปรแกรมขนาดเล็กเนื่องจากมันไม่ฉลาดพอที่จะลบรอบคี่บางอย่างในระบบประเภท (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

บนอินเทอร์เน็ต (ใช้งานโดยพันล้านคน / วัน)

Redirects, HTTP status code: 301

ตัวอย่างเช่นในเว็บไซต์สนับสนุนของ Dell (ไม่มีความผิดขอโทษ Dell):

หากคุณลบ TAG สนับสนุนจาก URL จากนั้นก็จะเข้าสู่ การเปลี่ยนเส้นทางที่ไม่มีที่สิ้นสุด ใน URL ต่อไปนี้ ###### เป็นแท็กสนับสนุนใด ๆ

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ที่นี่) เพียงเพราะอาร์เรย์นั้นลึกเกินไป (การอ้างอิงตนเอง) จากนั้นตัวรวบรวมขยะจะสิ้นสุดลงในการเรียกซ้ำ

ชวา

ฉันทำตรงกันข้ามแน่นอน - โปรแกรมที่ควรโยนข้อผิดพลาดล้นสแต็คอย่างชัดเจน แต่ไม่

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 ¹⁰ข้อยกเว้นต่อวินาทีซึ่งค่อนข้างใจกว้างตามมาตรฐานปัจจุบัน ภายใต้สมมติฐานเหล่านี้โปรแกรมจะยุติในเวลาประมาณ 1.7 × 10 ²⁹¹ปี เพื่อให้ได้มุมมองนี้อายุการใช้งานของดวงอาทิตย์ของเราจะอยู่ที่ประมาณ 10 ¹⁰ปีดังนั้นจึงเป็นทางออกที่ปลอดภัยที่จะไม่มีใครอยู่ใกล้เราที่จะเห็นโปรแกรมนี้ยุติ แม้ว่ามันจะไม่วนซ้ำไม่สิ้นสุด แต่ก็อาจจะเป็นเช่นนั้น

C #

โพสต์แรกดังนั้นโปรดไปง่าย ๆ กับฉัน

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

สิ่งนี้จะสร้างการติดตามแบบสแต็กคว้าเฟรมด้านบน (ซึ่งจะเป็นการเรียกครั้งสุดท้ายของเราMain()) รับเมธอดและเรียกใช้งาน

ชวา

• ใน 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จะถูก curried ซ้ำ ๆ ด้วยอาร์กิวเมนต์ที่มากขึ้นเรื่อย ๆ จนกว่าจะสามารถล้นสแต็กในการเรียกใช้ฟังก์ชันเดียว 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());
    }
}

วิธีที่ล้มเหลวคือมหากาพย์มันทำให้ใจฉันสมบูรณ์:

มันเป็นเพียงหนึ่งเฟรมของภาพแปลก ๆ ที่ไม่มีที่สิ้นสุด

นี่จะต้องเป็นสิ่งที่แปลกประหลาดที่สุดเท่าที่เคยมีมา มีใครอธิบายได้บ้าง เห็นได้ชัดว่าการเพิ่มจำนวนของช่องว่างที่ใช้ในการเยื้องทำให้บล็อกสีขาวเหล่านั้นปรากฏขึ้น มันเกิดขึ้นใน Win7 Enterprise x64 พร้อมด้วย. NET 4.5

ฉันยังไม่เห็นจุดจบของมัน หากคุณแทนที่System.Console.Outด้วยSystem.IO.Stream.Nullมันจะตายอย่างรวดเร็ว

คำอธิบายนั้นง่ายมาก ฉันสร้างคลาสที่มีคุณสมบัติเดียวและจะส่งคืนอินสแตนซ์ใหม่ของประเภทที่มีอยู่เสมอ ดังนั้นมันจึงเป็นลำดับชั้นของวัตถุที่ลึกอย่างไม่ จำกัด ตอนนี้เราต้องการบางสิ่งที่พยายามอ่านสิ่งนั้น นั่นคือสิ่งที่ฉันใช้XmlSerializerซึ่งทำอย่างนั้น และเห็นได้ชัดว่ามันใช้การสอบถามซ้ำ

ทุบตี

_(){ _;};_

ในขณะที่หลายคนอาจจำได้ว่าการเรียกซ้ำเป็นสิ่งที่ชัดเจนแต่ดูเหมือนว่าสวย ไม่มี?

เมื่อดำเนินการคุณจะได้รับการรับประกันในการดู:

Segmentation fault (core dumped)

Haskell

( แต่เป็นความจริงที่น่าเศร้าอย่างน้อยก็จนกว่าghc-7.6แม้ว่าจะมีO1หรือมากกว่าก็จะเพิ่มประสิทธิภาพของปัญหาที่เกิดขึ้นไป)

main = print $ sum [1 .. 100000000]

หูฟัง

สิ่งนี้จะสร้างวิธีการใหม่ในการบินซึ่ง
  สร้างวิธีการใหม่ในการบินซึ่ง
    จะสร้างวิธีการใหม่ในการบินซึ่ง
      ...
    ...
  ..
แล้วโอนไป

เครื่องเทศเล็ก ๆ น้อย ๆ เพิ่มขึ้นมาจากการเน้นความทรงจำกองซ้อนและหน่วยความจำกองในเวลาเดียวกันโดยการสร้างทั้งชื่อวิธีที่ยาวและยาวและจำนวนมากเป็นผู้รับในขณะที่เราล้มลงหลุม ... (แต่การเรียกซ้ำครั้งแรกเรา )

รวบรวมในจำนวนเต็ม:

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: มีการเพิ่ม "withoutUpdatingChangesFile:" เพื่อหลีกเลี่ยงการล้างข้อมูลแฟ้มบันทึกการเปลี่ยนแปลงถาวรของ Smalltalk หลังจากนั้น

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 #

การใช้งานที่ผิดพลาดของตัวดำเนินการแบบ 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;
        }
    }
}

อาจมีคนบอกว่าเห็นได้ชัดว่าoperator==เรียกตัวเองโดยใช้==โอเปอเรเตอร์ แต่โดยปกติคุณไม่คิดอย่าง==นั้นดังนั้นจึงง่ายที่จะตกหลุมพรางนั้น

เริ่มการตอบกลับโดยใช้ SnakeYAML

class A
{

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

แก้ไข: ungolfed มัน

มันขึ้นอยู่กับผู้อ่านที่จะหาวิธีการทำงาน: P (เคล็ดลับ: stackoverflow.com)

โดยวิธีการ: การเรียกซ้ำจะทำแบบไดนามิกโดย SnakeYAML (คุณจะสังเกตเห็นว่าคุณรู้วิธีการตรวจจับเขตข้อมูลที่มันทำให้เป็นอันดับและดูในPointซอร์สโค้ดของ)

แก้ไข: บอกวิธีการทำงาน:

SnakeYAML ค้นหาคู่ของgetXXXและsetXXXmthod ที่มีชื่อเดียวกันสำหรับXXXและ return type ของ getter เหมือนกับพารามิเตอร์ของ setter และน่าประหลาดใจที่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;
}