Als Programmierer kennen Sie sicherlich den Fehler eines Stapelüberlaufs aufgrund einer offensichtlichen Rekursion. Aber es gibt sicherlich viele seltsame und ungewöhnliche Möglichkeiten, Ihre Lieblingssprache dazu zu bringen, diesen Fehler auszuspucken.

Ziele:

1. Muss einen Stapelüberlauf verursachen, der auf der Fehlerausgabe deutlich sichtbar ist.
2. Darf keine offensichtliche Rekursion verwenden.

Beispiele für ungültige Programme:

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

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

Die kreativsten Wege sind die besten, da dies ein Beliebtheitswettbewerb ist . Vermeiden Sie langweilige offensichtliche Antworten wie diese:

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

Auch wenn ich jetzt eine Antwort akzeptiert habe, ist das Hinzufügen weiterer Antworten immer noch in Ordnung :)

Python

import sys
sys.setrecursionlimit(1)

Dies führt dazu, dass der Interpreter sofort ausfällt:

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

Anstatt eine Rekursion zu verwenden, wird der Stapel nur verkleinert, sodass er sofort überläuft.

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

Funktioniert durch Überschreiben der Rücksendeadresse. Kehrt also vor dem Anruf gzum Punkt in zurück . Funktioniert auf allen Plattformen, auf denen sich Rücksprungadressen auf dem Stapel befinden, jedoch möglicherweise Optimierungen erforderlich sind.mainf

Natürlich ist das Schreiben außerhalb eines Arrays ein undefiniertes Verhalten , und Sie können nicht garantieren, dass es zu einem Stapelüberlauf kommt, anstatt beispielsweise Ihren Schnurrbart blau zu färben. Details der Plattform-, Compiler- und Compiler-Flags können einen großen Unterschied machen.

JavaScript / DOM

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

    title = 'Kill me!';
}

Wenn Sie Ihren Browser beenden möchten, probieren Sie dies in der Konsole aus.

Java

Habe hier irgendwo so etwas gesehen:

Bearbeiten: Gefunden, wo ich es gesehen habe: Joe Ks Antwort auf das kürzeste Programm, das den StackOverflow-Fehler auslöst

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

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

Das kann einige Java-Anfänger verwirren. Der rekursive Aufruf wird einfach ausgeblendet. val + thiswird val + this.toString()weil valist ein String.

Sehen Sie es hier laufen: http://ideone.com/Z0sXiD

C

Ziemlich leicht:

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

Nicht rekursiver Stapelüberlauf in C

Nicht übereinstimmende Konventionen aufrufen.

typedef void __stdcall (* ptr) (int);

void __cdecl hello (int x) { }

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

Kompilieren mit gcc -O0.

__cdeclFunktionen erwarten, dass der Aufrufer den Stapel __stdcallaufräumt , und erwarten , dass der Angerufene dies tut. Durch Aufrufen des typecast-Funktionszeigers wird die Bereinigung also nie durchgeführt. mainDer Parameter wird bei jedem Aufruf auf den Stapel verschoben, aber es wird kein Popup ausgeführt und schließlich der Stapelfüllungen.

JavaScript

window.toString = String.toLocaleString;
+this;

Ich war frustriert darüber, dass Java 7 und Java 8 in meiner vorherigen Antwort gegen meinen bösen Code immun sind . Also entschied ich, dass ein Patch dafür notwendig war.

Erfolg! Ich habe einen printStackTrace()Wurf gemacht StackOverflowError. printStackTrace()wird häufig zum Debuggen und Protokollieren verwendet, und niemand vermutet, dass dies gefährlich sein könnte. Es ist nicht schwer zu erkennen, dass dieser Code missbraucht werden kann, um einige schwerwiegende Sicherheitsprobleme zu verursachen:

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

Einige Leute denken vielleicht, dass dies eine offensichtliche Rekursion ist. Es ist nicht. Der EvilExceptionKonstruktor ruft die getCause()Methode nicht auf, sodass eine Ausnahme tatsächlich sicher ausgelöst werden kann. Das Aufrufen der getCause()Methode führt auch nicht zu einer StackOverflowError. Die Rekursion befindet sich innerhalb des normalerweise unerwarteten printStackTrace()Verhaltens von JDK und in der Bibliothek von Drittanbietern zum Debuggen und Protokollieren, die zum Untersuchen der Ausnahme verwendet werden. Ferner ist es wahrscheinlich, dass der Ort, an dem die Ausnahme ausgelöst wird, sehr weit von dem Ort entfernt ist, an dem sie behandelt wird.

Wie auch immer, hier ist ein Code, der ein wirft StackOverflowErrorund schließlich keine rekursiven Methodenaufrufe enthält. Das StackOverflowErrorpassiert außerhalb der mainMethode in JDKs 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:

Wenn wir vergessen haben, von printHello zurückzukehren, springen wir gleich wieder in _start.

C ++ zur Kompilierungszeit

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

template <>
struct S<0> {};

template
struct S<-1>;

$ g ++ -c test.cc -ftemplate-depth = 40000
g ++: Interner Compilerfehler: Segmentierungsfehler (Programm cc1plus)
Bitte reichen Sie einen vollständigen Fehlerbericht ein.
gegebenenfalls mit vorverarbeiteter Quelle.
Anweisungen finden Sie unter.

Es gibt keine Rekursion dieser Quelldatei, keine der Klassen hat sich selbst als Basisklasse, auch nicht indirekt. (In C ++, in einer Schablonenklasse wie dieser, S<1>und S<2>sind völlig unterschiedliche Klassen.) Der Segmentierungsfehler ist auf einen Stapelüberlauf nach einer Rekursion im Compiler zurückzuführen.

Bash (Gefahrenalarm)

while true
do 
  mkdir x
  cd x
done

Streng genommen führt dies nicht direkt zu einem Stapelüberlauf, sondern zu einer Situation , die möglicherweise als " anhaltend stapelüberlauferzeugend " bezeichnet wird: Wenn Sie dies ausführen, bis Ihre Festplatte voll ist, und das Durcheinander mit "rm -rf" beseitigen möchten x ", dieser wird getroffen.

Dies ist jedoch nicht auf allen Systemen der Fall. Einige sind robuster als andere.

Große Gefahr WARNUNG:

Einige Systeme handhaben dies sehr schlecht und es kann schwierig sein, die Daten zu bereinigen (da "rm -rf" selbst auf ein Wiederherstellungsproblem stößt). Möglicherweise müssen Sie ein ähnliches Skript für die Bereinigung schreiben.

Versuchen Sie dies besser in einer Scratch-VM, wenn Sie sich nicht sicher sind.

PS: Gleiches gilt natürlich auch, wenn dies in einem Batch-Skript programmiert oder durchgeführt wird.
PPS: Es kann interessant sein, einen Kommentar von Ihnen zu erhalten, wie sich Ihr bestimmtes System verhält ...

Java

Eine schöne von Java Puzzlers . Was wird gedruckt?

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

Es schlägt tatsächlich mit einem StackOverflowError fehl.

Die Ausnahme im Konstruktor ist nur ein roter Hering. Das sagt das Buch dazu:

Wenn Sie einen Konstruktor aufrufen, werden die Initialisierer der Instanzvariablen vor dem Rumpf des Konstruktors ausgeführt . In diesem Fall internalInstanceruft der Initialisierer für die Variable den Konstruktor rekursiv auf. Dieser Konstruktor wiederum initialisiert sein eigenes internalInstanceFeld, indem er den Reluctant-Konstruktor erneut usw. unendlich aufruft. Diese rekursiven Aufrufe führen dazu, dass a, StackOverflowErrorbevor der Konstruktorkörper jemals die Möglichkeit erhält, ausgeführt zu werden. Da StackOverflowErrores sich um einen Untertyp von Erroranstatt handelt Exception, wird er von der catch-Klausel in mainnicht erfasst.

Latex

\end\end

Der Eingabestapel läuft über, weil er sich \endwiederholt in einer Endlosschleife erweitert, wie hier erläutert .

TeX schlägt mit a TeX capacity exceeded, sorry [input stack size=5000]oder ähnlich fehl .

BF

Wird irgendwann der Stack überlaufen, hängt nur davon ab, wie lange der Interpreter den Stack macht ...

+[>+]

C #, zur Kompilierungszeit

Es gibt verschiedene Möglichkeiten, den Microsoft C # -Compiler dazu zu bringen, seinen Stapel zu sprengen. Jedes Mal, wenn Sie einen "Ausdruck ist zu komplex zum Kompilieren" -Fehler vom C # -Compiler sehen, der mit ziemlicher Sicherheit darauf zurückzuführen ist, dass der Stack durchgebrannt ist.

Der Parser ist ein rekursiver Abstieg, sodass alle ausreichend tief verschachtelten Sprachstrukturen den Stapel sprengen:

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

Der Ausdrucksparser ist ziemlich klug, wenn es darum geht, Rekursionen auf der Seite zu eliminieren, auf der häufig Rekursionen auftreten. Gewöhnlich:

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

die einen enorm tiefen Analysebaum baut, wird den Stapel nicht sprengen. Aber wenn Sie die Rekursion auf der anderen Seite erzwingen:

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

dann kann der Stapel geblasen werden.

Diese haben die unelegante Eigenschaft, dass das Programm sehr groß ist. Es ist auch möglich, den Semantikanalysator mit einem kleinen Programm in unbegrenzte Rekursionen zu versetzen, da er nicht intelligent genug ist, um bestimmte ungerade Zyklen im Typensystem zu beseitigen. (Roslyn könnte dies verbessern.)

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? 

Ich beschreibe hier, warum diese Analyse in eine unendliche Rekursion geht:

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

und für viele weitere interessante Beispiele sollten Sie dieses Papier lesen:

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

Im Internet (von Milliarden Menschen pro Tag genutzt)

Redirects, HTTP status code: 301

Zum Beispiel auf der Dell Support-Website (keine Beleidigung, sorry Dell):

Wenn Sie das Support-TAG von der URL entfernen, werden unendlich viele Weiterleitungen ausgeführt . In der folgenden URL steht ###### für ein beliebiges Support-TAG.

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

Ich glaube, das entspricht einem Stapelüberlauf.

PHP

Ein Stapelüberlauf, der nur mit Schleifenelementen durchgeführt wird.

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

Erklärung (Hover um den Spoiler zu sehen):

Das Programm schlägt fehl, wenn der Interpreter versucht, das $tmpArray zu entfernen (wenn er es $tmphier neu zuordnet ). Nur weil das Array zu tief ist (selbstreferenzierend) und der Garbage Collector dann in einer Rekursion endet.

Java

Ich habe genau das Gegenteil getan - ein Programm, das offensichtlich einen Stapelüberlauffehler auslösen sollte, dies jedoch nicht.

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

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

Hinweis: Das Programm wird in O (2 ⁿ ) ausgeführt und n ist die Größe des Stapels (normalerweise 1024).

Von Java Puzzlers # 45:

Nehmen wir an, unsere Maschine kann 10 ¹⁰ Aufrufe pro Sekunde ausführen und 10 ¹⁰ Ausnahmen pro Sekunde generieren , was nach aktuellen Standards recht großzügig ist. Unter diesen Voraussetzungen endet das Programm in etwa 1,7 × 10 ²⁹¹ Jahren. Aus diesem Grund wird die Lebensdauer unserer Sonne auf 10 bis ¹⁰ Jahre geschätzt. Es ist also sicher, dass niemand von uns anwesend sein wird, wenn dieses Programm endet. Obwohl es keine Endlosschleife ist, könnte es genauso gut sein.

C #

Erster Beitrag, also bitte schont mich.

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

Dadurch wird einfach ein Stack-Trace erstellt, der oberste Frame (der unser letzter Aufruf ist Main()) wird abgerufen, die Methode abgerufen und aufgerufen.

Java

• Tritt in Java 5 printStackTrace()in eine Endlosschleife ein.
• In Java 6 printStackTrace()wirft StackOverflowError.
• In Java 7 und 8 wurde es behoben.

Das Verrückte ist, dass es in Java 5 und 6 nicht vom Benutzercode kommt, sondern im JDK-Code. Niemand vernünftiger Verdächtiger, printStackTrace()dessen Ausführung gefährlich sein kann.

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: Nicht rekursive, iterative Funktionsmutation

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

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

Hier gibt es überhaupt keine Rekursion. fwird wiederholt mit immer mehr Argumenten versehen, bis der Stack in einem einzigen Funktionsaufruf überlaufen kann . Der console.logTeil ist optional, wenn Sie sehen möchten, wie viele Argumente dafür erforderlich sind. Es sorgt auch dafür, dass clevere JS-Motoren dies nicht wegoptimieren.

Code-Golf-Version in CoffeeScript, 28 Zeichen:

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

C # mit einem epischen Fehler

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

Die Art und Weise, wie es fehlschlägt, ist episch und hat mich völlig umgehauen:

Es ist nur ein Bild aus einer scheinbar unendlichen Reihe seltsamer Bilder.

Das muss das Seltsamste sein, was es je gab. Kann jemand erklären? Anscheinend werden diese weißen Blöcke durch die immer größere Anzahl von Leerzeichen angezeigt, die zum Einrücken verwendet werden. Es passiert auf einem Win7 Enterprise x64 mit .NET 4.5.

Ich habe das Ende noch nicht gesehen. Wenn Sie ersetzen System.Console.Outmit System.IO.Stream.Null, stirbt es ziemlich schnell.

Die Erklärung ist ziemlich einfach. Ich erstelle eine Klasse mit einer einzelnen Eigenschaft und sie gibt immer eine neue Instanz ihres enthaltenden Typs zurück. Es ist also eine unendlich tiefe Objekthierarchie. Jetzt brauchen wir etwas, das versucht, das durchzulesen. Dort verwende ich die XmlSerializer, die genau das macht. Und anscheinend verwendet es eine Rekursion.

Bash

_(){ _;};_

Zwar mögen viele erkennen, dass die Rekursion offensichtlich ist , aber es scheint hübsch. Nein?

Bei der Ausführung sehen Sie garantiert:

Segmentation fault (core dumped)

Haskell

(traurig, aber wahr, bis zumindest ghc-7.6, obwohl mit O1oder mehr das Problem wegoptimiert wird)

main = print $ sum [1 .. 100000000]

Smalltalk

Dies erzeugt eine neue Methode im laufenden Betrieb, die
  eine neue Methode im laufenden Betrieb erzeugt, die
    eine neue Methode im laufenden Betrieb erzeugt, die
      ...
    ...
  ...
und dann zu ihr überträgt.

Ein zusätzliches Plus an Würze ergibt sich aus der gleichzeitigen Belastung von Stapelspeicher UND Heapspeicher, indem sowohl ein längerer als auch ein längerer Methodenname und eine große Zahl als Empfänger erstellt werden, wenn wir das Loch runterfallen ... (aber die Rekursion trifft uns zuerst ).

kompiliere in 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.

Dann springen Sie, indem Sie auswerten "2 downTheRabbitHole"...
... nach einer Weile werden Sie in einem Debugger enden, der eine RecursionException anzeigt.

Dann musst du das ganze Durcheinander beseitigen (sowohl SmallInteger als auch LargeInteger haben jetzt eine Menge Wunderland-Code):

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

Oder verbringen Sie einige Zeit im Browser und entfernen Sie das Wunderland von Alice.

Hier sind einige aus dem Kopf der Spur:

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: Die Datei "withoutUpdatingChangesFile:" wurde hinzugefügt, um zu vermeiden, dass die persistente Änderungsprotokolldatei von Smalltalk anschließend bereinigt werden muss.

PPS: Danke für die Herausforderung: Über etwas Neues und Innovatives nachzudenken hat Spaß gemacht!

PPPS: Ich stelle fest, dass einige Smalltalk-Dialekte / -Versionen überlaufende Stack-Frames auf den Heap kopieren. Daher kann es stattdessen zu Speichermangel kommen.

C #

Wirklich groß struct, keine Rekursion, reines C #, kein unsicherer Code.

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

Als Kicker stürzt das Debug-Fenster ab {Cannot evaluate expression because the current thread is in a stack overflow state.}

Und die generische Version (danke für den Vorschlag 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 #

Fehlerhafte Implementierung des ==Operators 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;
        }
    }
}

Man könnte sagen, es liegt auf der Hand, dass operator==sich der ==Operator selbst aufruft , aber normalerweise denken Sie nicht ==so.

Antwort mit SnakeYAML starten

class A
{

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

Edit: es ungolfed

Der Leser muss herausfinden, wie das funktioniert: P (Tipp: stackoverflow.com)

Übrigens: Die Rekursion wird dynamisch von SnakeYAML erstellt (Sie werden feststellen, ob Sie wissen, wie es die Felder erkennt, die es serialisiert, und dann hineinschaut) Point den Quellcode ).

Bearbeiten: erzählen, wie das funktioniert:

SnakeYAML sucht nach einem Paar von getXXXund setXXXmthod mit demselben Namen für XXXund return type des Getters ist derselbe wie parameter of setter; und überraschenderweise hat die PointKlasse ein Point getLocation()und void setLocation(Point P)das kehrt zurück; SnakeYAML merkt es nicht und wiederholt diese Eigenart und StackOverflows. Entdeckt, dass man, wenn man mit ihnen in einem arbeitet HashMapund auf stackoverflow.com danach fragt.

C #

falsch implementierter Property Getter

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

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