Là một lập trình viên, bạn chắc chắn biết lỗi tràn ngăn xếp do đệ quy rõ ràng. Nhưng chắc chắn có nhiều cách kỳ lạ và bất thường để khiến ngôn ngữ yêu thích của bạn thoát ra lỗi đó.

Mục tiêu:

1. Phải gây ra lỗi tràn ngăn xếp hiển thị rõ ràng trên đầu ra lỗi.
2. Không được phép sử dụng một đệ quy rõ ràng.

Ví dụ về các chương trình không hợp lệ:

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

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

Những cách sáng tạo nhất là tốt nhất vì đây là một cuộc thi phổ biến . Tức là tránh những câu trả lời rõ ràng nhàm chán như thế này:

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

Mặc dù tôi đã chấp nhận một câu trả lời ngay bây giờ, nhưng thêm nhiều câu trả lời vẫn ổn :)

Con trăn

import sys
sys.setrecursionlimit(1)

Điều này sẽ khiến trình thông dịch bị lỗi ngay lập tức:

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

Thay vì sử dụng đệ quy, nó chỉ thu nhỏ stack nên nó sẽ tràn ngay lập tức.

Con trăn

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

C / Linux 32 bit

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

Hoạt động bằng cách ghi đè địa chỉ trả về, Vì vậy, gquay trở lại điểm maintrước khi gọi f. Sẽ hoạt động cho bất kỳ nền tảng nào có địa chỉ trả về trên ngăn xếp, nhưng có thể yêu cầu chỉnh sửa.

Tất nhiên, viết bên ngoài một mảng là hành vi không xác định và bạn không có gì đảm bảo rằng nó sẽ gây ra lỗi tràn ngăn xếp hơn là nói, tô màu ria mép của bạn. Chi tiết về nền tảng, trình biên dịch và cờ biên dịch có thể tạo ra sự khác biệt lớn.

JavaScript / DOM

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

    title = 'Kill me!';
}

Nếu bạn muốn giết trình duyệt của mình, hãy thử điều đó trong bảng điều khiển.

Java

Nhìn thấy một cái gì đó như thế này ở đâu đó quanh đây:

Chỉnh sửa: Tìm thấy nơi tôi thấy: Câu trả lời của Joe K cho chương trình ngắn nhất gây ra lỗi StackOverflow

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

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

Điều đó có thể gây nhầm lẫn cho một số người mới bắt đầu Java. Nó chỉ đơn giản là ẩn cuộc gọi đệ quy. val + thistrở thành val + this.toString()bởi vì vallà một Chuỗi.

Xem nó chạy ở đây: http://ideone.com/Z0sXiD

C

Khá dễ dàng:

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

Tràn ngăn xếp không đệ quy trong C

Gọi quy ước không khớp.

typedef void __stdcall (* ptr) (int);

void __cdecl hello (int x) { }

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

Biên dịch với gcc -O0.

__cdeclcác hàm mong muốn người gọi dọn sạch ngăn xếp và __stdcallmong đợi callee thực hiện nó, vì vậy bằng cách gọi qua con trỏ hàm typecast, việc dọn dẹp không bao giờ được thực hiện - mainđẩy tham số lên ngăn xếp cho mỗi cuộc gọi nhưng không có gì bật ra và cuối cùng là chồng chất đầy.

JavaScript

window.toString = String.toLocaleString;
+this;

Tôi đã thất vọng bởi thực tế là java 7 và java 8 miễn nhiễm với mã xấu trong câu trả lời trước của tôi . Vì vậy, tôi quyết định rằng một bản vá cho điều đó là cần thiết.

Sự thành công! Tôi đã printStackTrace()ném a StackOverflowError. printStackTrace()thường được sử dụng để gỡ lỗi và ghi nhật ký và không ai nghi ngờ rằng nó có thể nguy hiểm. Không khó để thấy rằng mã này có thể bị lạm dụng để tạo ra một số vấn đề bảo mật nghiêm trọng:

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

Một số người có thể nghĩ rằng đây là một đệ quy rõ ràng. Không phải vậy. Hàm EvilExceptiontạo không gọi getCause()phương thức, do đó, ngoại lệ thực sự có thể được ném an toàn. Gọi getCause()phương thức sẽ không dẫn đến một StackOverflowErrortrong hai. Đệ quy nằm trong printStackTrace()hành vi không được xem xét thông thường của JDK và bất kỳ thư viện bên thứ 3 nào để gỡ lỗi và ghi nhật ký được sử dụng để kiểm tra ngoại lệ. Hơn nữa, có khả năng nơi ném ngoại lệ rất xa so với nơi được xử lý.

Dù sao, đây là một mã mà ném một StackOverflowErrorvà không chứa các cuộc gọi phương thức đệ quy sau tất cả. Điều này StackOverflowErrorxảy ra bên ngoài mainphương thức, trong 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"

Linux x86 Hội 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

Spoiler:

Quên trở về từ printHello, vì vậy chúng tôi nhảy ngay vào _start một lần nữa.

C ++ tại thời gian biên dịch

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

template <>
struct S<0> {};

template
struct S<-1>;

$ g ++ -c test.cc -ftemplate-height = 40000
g ++: lỗi trình biên dịch nội bộ: Lỗi phân đoạn (chương trình cc1plus)
Vui lòng gửi báo cáo lỗi đầy đủ,
với nguồn tiền xử lý nếu thích hợp.
Xem để được hướng dẫn.

Không có đệ quy tệp nguồn này, không phải một trong các lớp có chính nó là một lớp cơ sở, thậm chí không gián tiếp. (Trong C ++, trong một lớp mẫu như thế này S<1>và S<2>là các lớp hoàn toàn khác biệt.) Lỗi phân đoạn là do tràn ngăn xếp sau khi đệ quy trong trình biên dịch.

Bash (Cảnh báo nguy hiểm)

while true
do 
  mkdir x
  cd x
done

Nói một cách chính xác, điều đó sẽ không trực tiếp ngăn xếp tràn, nhưng tạo ra cái có thể được gắn nhãn là " tình huống tạo chồng quá dòng liên tục ": khi bạn chạy nó cho đến khi đĩa của bạn đầy, và muốn xóa mớ hỗn độn bằng "rm -rf x ", cái đó bị đánh.

Nó không xảy ra trên tất cả các hệ thống, mặc dù. Một số mạnh mẽ hơn những người khác.

CẢNH BÁO nguy hiểm lớn:

một số hệ thống xử lý việc này rất tệ và bạn có thể rất khó khăn trong việc dọn dẹp (vì bản thân "rm -rf" sẽ gặp phải vấn đề truy hồi). Bạn có thể phải viết một kịch bản tương tự để dọn dẹp.

Tốt hơn nên thử điều này trong một VM đầu nếu không chắc chắn.

PS: tất nhiên áp dụng tương tự, nếu được lập trình hoặc thực hiện trong một tập lệnh bó.
PPS: có thể can thiệp để nhận được bình luận từ bạn, cách hệ thống cụ thể của bạn hoạt động ...

Java

Một cái hay từ Java Puzzlers . Nó in cái gì?

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

Nó thực sự thất bại với StackOverflowError.

Ngoại lệ trong hàm tạo chỉ là một cá trích đỏ. Đây là những gì cuốn sách đã nói về nó:

Khi bạn gọi một hàm tạo, các bộ khởi tạo biến thể hiện chạy trước phần thân của hàm tạo . Trong trường hợp này, trình khởi tạo cho biến internalInstancegọi hàm tạo theo cách đệ quy. Ngược lại, hàm tạo đó khởi tạo trường của chính nó internalInstancebằng cách gọi lại hàm tạo bất đắc dĩ, v.v., ad infinitum. Các yêu cầu đệ quy này gây ra StackOverflowErrortrước khi cơ quan xây dựng có cơ hội thực thi. Bởi vì StackOverflowErrorlà một kiểu con Errorthay vì Exception, mệnh đề bắt trong mainkhông bắt được nó.

Mủ cao su

\end\end

Ngăn xếp đầu vào tràn vì \endliên tục mở rộng chính nó trong một vòng lặp vô hạn, như được giải thích ở đây .

TeX thất bại với một TeX capacity exceeded, sorry [input stack size=5000]hoặc tương tự.

BF

Cuối cùng sẽ tràn vào ngăn xếp, chỉ phụ thuộc vào thời gian trình thông dịch tạo ra ngăn xếp ...

+[>+]

C #, tại thời điểm biên dịch

Có một số cách để khiến trình biên dịch Microsoft C # thổi tung ngăn xếp của nó; bất cứ khi nào bạn thấy một lỗi "biểu thức quá phức tạp để biên dịch" từ trình biên dịch C # gần như chắc chắn là do ngăn xếp đã bị thổi.

Trình phân tích cú pháp có nguồn gốc đệ quy, do đó, bất kỳ cấu trúc ngôn ngữ nào được lồng đủ sâu sẽ thổi vào ngăn xếp:

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

Trình phân tích cú pháp biểu thức khá thông minh về việc loại bỏ các lần truy cập ở phía thường được đệ quy. Thông thường:

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

xây dựng một cây phân tích cực kỳ sâu, sẽ không thổi tung đống. Nhưng nếu bạn buộc đệ quy xảy ra ở phía bên kia:

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

sau đó ngăn xếp có thể được thổi.

Những cái này có tài sản không phù hợp mà chương trình rất lớn. Cũng có thể làm cho bộ phân tích ngữ nghĩa đi vào các lần thu hồi không giới hạn với một chương trình nhỏ vì nó không đủ thông minh để loại bỏ các chu kỳ kỳ lạ nhất định trong hệ thống loại. (Roslyn có thể cải thiện điều này.)

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? 

Tôi mô tả lý do tại sao phân tích này đi vào một đệ quy vô hạn ở đây:

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

và để biết thêm nhiều ví dụ thú vị bạn nên đọc bài viết này:

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

Trên Internet (được sử dụng bởi tỷ người / ngày)

Redirects, HTTP status code: 301

Ví dụ: trên trang web hỗ trợ của Dell (không vi phạm, xin lỗi Dell):

Nếu bạn xóa TAG hỗ trợ khỏi URL thì nó sẽ chuyển hướng vô hạn . Trong URL sau, ###### là bất kỳ TAG hỗ trợ nào.

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

Tôi tin rằng nó tương đương với một chồng tràn.

PHP

Một stackoverflow được thực hiện chỉ với các phần tử lặp.

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

Giải thích (di chuột để xem spoiler):

Chương trình sẽ segfault khi trình thông dịch cố gắng thu gom $tmpmảng đi (khi gán lại $tmpở đây). Chỉ vì mảng quá sâu (tự tham chiếu) và sau đó trình thu gom rác kết thúc trong một đệ quy.

Java

Tôi đã làm ngược lại chính xác - một chương trình rõ ràng sẽ gây ra lỗi tràn ngăn xếp, nhưng không.

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

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

Gợi ý: chương trình chạy trong thời gian O (2 ⁿ ) và n là kích thước của ngăn xếp (thường là 1024).

Từ Java Puzzlers # 45:

Giả sử rằng máy của chúng tôi có thể thực hiện 10 ¹⁰ cuộc gọi mỗi giây và tạo ra 10 ¹⁰ ngoại lệ mỗi giây, khá hào phóng theo các tiêu chuẩn hiện tại. Theo các giả định này, chương trình sẽ chấm dứt trong khoảng 1,7 × 10 ²⁹¹ năm. Để đặt điều này trong viễn cảnh, thời gian tồn tại của mặt trời của chúng ta được ước tính là 10 ¹⁰ năm, do đó, đặt cược an toàn là không ai trong chúng ta sẽ ở xung quanh để thấy chương trình này chấm dứt. Mặc dù nó không phải là một vòng lặp vô hạn, nó cũng có thể như vậy.

C #

Bài đầu tiên, vì vậy xin vui lòng đi dễ dàng trên tôi.

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

Điều này chỉ đơn giản là tạo ra một dấu vết ngăn xếp, lấy khung trên cùng (sẽ là lệnh gọi cuối cùng của chúng ta Main()), lấy phương thức và gọi nó.

Java

• Trong Java 5, printStackTrace()nhập một vòng lặp vô hạn.
• Trong Java 6, printStackTrace()ném StackOverflowError.
• Trong Java 7 và 8, nó đã được sửa.

Điều điên rồ là trong Java 5 và 6, nó không xuất phát từ mã người dùng, nó xảy ra trong mã của JDK. Không ai nghi ngờ hợp lý printStackTrace()có thể nguy hiểm để thực hiện.

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: Không đột biến, đột biến hàm lặp

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

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

Không có đệ quy nào ở đây cả. fsẽ được lặp đi lặp lại với nhiều đối số hơn và nhiều hơn cho đến khi nó có thể tràn vào ngăn xếp trong một lệnh gọi hàm duy nhất. Phần console.lognày là tùy chọn trong trường hợp bạn muốn xem cần bao nhiêu đối số để thực hiện. Nó cũng đảm bảo rằng các công cụ JS thông minh sẽ không tối ưu hóa điều này.

Phiên bản mã golf trong CoffeeScript, 28 ký tự:

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

C # với một thất bại sử thi

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

Cách nó thất bại là tuyệt vời, nó hoàn toàn thổi vào tâm trí tôi:

Nó chỉ là một khung hình của một chuỗi những hình ảnh kỳ lạ dường như vô tận.

Đây phải là điều kỳ lạ nhất. Ai có thể giải thích? Rõ ràng, lượng không gian ngày càng tăng được sử dụng để thụt đầu dòng khiến những khối trắng đó xuất hiện. Nó xảy ra trên Win7 Enterprise x64 với .NET 4.5.

Tôi chưa thực sự nhìn thấy sự kết thúc của nó. Nếu bạn thay thế System.Console.Outbằng System.IO.Stream.Null, nó chết khá nhanh.

Lời giải thích khá đơn giản. Tôi tạo một lớp có một thuộc tính duy nhất và nó luôn trả về một thể hiện mới của kiểu chứa nó. Vì vậy, nó là một hệ thống phân cấp đối tượng sâu vô hạn. Bây giờ chúng ta cần một cái gì đó cố gắng đọc qua đó. Đó là nơi tôi sử dụng XmlSerializer, chỉ có thế. Và rõ ràng, nó sử dụng đệ quy.

bash

_(){ _;};_

Trong khi nhiều người có thể nhận ra rằng đệ quy là rõ ràng , nhưng nó có vẻ khá. Không?

Khi thực hiện, bạn được đảm bảo để xem:

Segmentation fault (core dumped)

Haskell

(buồn nhưng đúng cho đến khi ít nhất ghc-7.6, dù có O1hoặc nhiều hơn nó sẽ tối ưu hóa vấn đề)

main = print $ sum [1 .. 100000000]

Smalltalk

Điều này tạo ra một phương thức mới khi đang bay,
  tạo ra một phương thức mới khi đang bay,
    tạo ra một phương thức mới khi đang bay,
      ...
    ...
  ..
và sau đó chuyển sang phương thức đó.

Một gia vị nhỏ thêm đến từ bộ nhớ ngăn xếp căng thẳng VÀ bộ nhớ heap cùng một lúc, bằng cách tạo cả tên phương thức dài hơn và dài hơn, và một số lượng lớn là máy thu, khi chúng ta rơi xuống lỗ hổng ... (nhưng đệ quy đánh vào chúng ta trước ).

biên dịch trong 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.

sau đó nhảy, bằng cách đánh giá "2 downTheRabbitHole"...
... sau một thời gian, bạn sẽ kết thúc trình gỡ lỗi, hiển thị RecursionException.

Sau đó, bạn phải dọn dẹp tất cả mớ hỗn độn (cả SmallInteger và LargeInteger hiện có rất nhiều mã wonderland):

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

hoặc người khác dành một chút thời gian trong trình duyệt, loại bỏ xứ sở thần tiên.

Đây là một số từ đầu của dấu vết:

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:" đã được thêm vào để tránh phải dọn dẹp tệp nhật ký thay đổi liên tục của Smalltalk sau đó.

PPS: cảm ơn vì thử thách: nghĩ về điều gì đó mới mẻ và sáng tạo thật thú vị!

PPPS: Tôi muốn lưu ý rằng một số phương ngữ / phiên bản Smalltalk sao chép các khung stack tràn vào heap - vì vậy chúng có thể gặp phải tình huống hết bộ nhớ.

C #

Thực sự lớn struct, không có đệ quy, C # thuần túy, không phải mã không an toàn.

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

như một kicker, nó phá vỡ các cửa sổ gỡ lỗi nói rằng {Cannot evaluate expression because the current thread is in a stack overflow state.}

Và phiên bản chung (cảm ơn vì gợi ý 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 #

Triển khai lỗi của ==toán tử 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;
        }
    }
}

Người ta có thể nói rõ ràng là operator==tự gọi mình bằng cách sử dụng ==toán tử, nhưng bạn thường không nghĩ ==như vậy, vì vậy rất dễ rơi vào cái bẫy đó.

Bắt đầu trả lời bằng SnakeYAML

class A
{

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

Chỉnh sửa: không hiểu

Tùy thuộc vào người đọc để tìm hiểu cách thức hoạt động: P (mẹo: stackoverflow.com)

Nhân tiện: đệ quy được tạo tự động bởi SnakeYAML (bạn sẽ chú ý nếu bạn biết cách nó phát hiện các trường mà nó tuần tự hóa và xem sau đó trong Pointmã nguồn)

Chỉnh sửa: cho biết cách thức hoạt động của một:

SnakeYAML tìm kiếm một cặp getXXXvà setXXXmthod có cùng tên cho XXXvà kiểu trả về của getter giống như tham số của setter; và đáng ngạc nhiên là Pointlớp có một Point getLocation()và void setLocation(Point P)nó tự trả về; SnakeYAML không chú ý đến nó và đệ quy về điều đó và StackOverflows. Phát hiện ra cái đó khi làm việc với họ bên trong a HashMapvà hỏi về stackoverflow.com trên đó.

C #

thực hiện sai tài sản getter

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

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