Bir programcı olarak, bariz bir özyinelemeden dolayı yığın taşması hatasını kesinlikle biliyorsunuzdur. Ancak en sevdiğiniz dili bu hatayı gidermek için kullanabileceğiniz çok garip ve sıradışı yollar var.

Amaç:

1. Hata çıktısında açıkça görülebilen bir yığın taşmasına neden olmalıdır.
2. Belirgin bir özyineleme kullanmasına izin verilmiyor.

Geçersiz programlara örnekler:

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

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

En yaratıcı yollar, bu popülerlik yarışması için en iyisidir . Yani, bunun gibi bariz cevapları sıkmaktan kaçının:

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

Şimdi bir cevap kabul etmeme rağmen, daha fazla cevap eklemek hala sorun değil :)

piton

import sys
sys.setrecursionlimit(1)

Bu, tercümanın derhal başarısız olmasına neden olacaktır:

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

Özyineleme kullanmak yerine, yığını hemen küçülecek şekilde küçültür.

piton

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

İade adresinin üzerine yazarak çalışır, Bu yüzden aramadan önce go noktaya geri döner . İade adreslerinin yığında olduğu herhangi bir platform için çalışacak, ancak tweaks gerektirebilir.mainf

Tabii ki, bir dizinin dışına yazmak tanımsız bir davranıştır ve bıyık mavinizi boyamak yerine yığma taşmasına neden olacağının garantisi yoktur. Platform, derleyici ve derleme bayraklarının detayları büyük bir fark yaratabilir.

JavaScript / DOM

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

    title = 'Kill me!';
}

Tarayıcınızı öldürmek istiyorsanız, bunu konsolda deneyin.

Java

Buralarda bir yerde böyle bir şey gördüm:

Düzenleme: Gördüğüm yerde bulundu: Joe K'nin StackOverflow Hatası veren kısa programın cevabı

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

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

Bu bazı Java yeni başlayanlarını şaşırtabilir. Sadece özyinelemeli çağrıyı gizler. val + thisolur val + this.toString()çünkü valbir String.

Burada çalıştığını görün: http://ideone.com/Z0sXiD

C

Oldukça kolay:

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

Özyinelemeyen yığın taşması C

Çağrılan kongre uyuşmazlığı.

typedef void __stdcall (* ptr) (int);

void __cdecl hello (int x) { }

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

İle derleyin gcc -O0.

__cdeclfonksiyonlar arayanın yığını temizlemesini bekler ve arayanın yapmasını __stdcallbekler, bu yüzden typecast işlevi imlecini çağırarak temizleme işlemi asla yapılmaz - mainparametreyi her arama için yığına iter ancak hiçbir şey çıkarmaz ve sonuçta yığın doldurur.

JavaScript

window.toString = String.toLocaleString;
+this;

Java 7 ve Java 8'in önceki cevabımdaki kötülük koduma karşı bağışık olmaları beni çok etkiledi . Böylece bunun için bir yamanın gerekli olduğuna karar verdim.

Başarı! printStackTrace()Atıp attım StackOverflowError. printStackTrace()genellikle hata ayıklama ve kayıt için kullanılır ve hiç kimse bunun tehlikeli olabileceğinden şüphelenmez. Bazı ciddi güvenlik sorunları oluşturmak için bu kodun kötüye kullanılabileceğini görmek zor değil:

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

Bazı insanlar bunun bariz bir özyineleme olduğunu düşünebilir. O değil. EvilExceptionYapıcı çağırır gelmez getCause()bu durum aslında tüm sonra güvenle atılan böylece, yöntem. getCause()Yöntemin çağrılması StackOverflowErrorikisinde de sonuçlanmaz . Özyineleme, JDK'nın normalde beklenmeyen printStackTrace()davranışları ve istisnayı incelemek için kullanılan hata ayıklama ve kayıt için kullanılan 3. parti kitaplığın içindedir . Ayrıca, istisnanın atıldığı yerin, kullanıldığı yerden çok uzakta olması muhtemeldir.

Neyse, işte a atan StackOverflowErrorve özyinelemeli yöntem çağrıları içermeyen bir kod . StackOverflowErrorDışarıda olup mainJDK en içinde, yöntemin 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 Birleşimi

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

Bir şeyin önceden reklamı:

PrintHello'dan dönmeyi unutmak, böylece tekrar _start'a atlayacağız.

Derleme zamanında 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 ++: dahili derleyici hatası: Segmentasyon hatası (cc1plus programı)
Lütfen tam bir hata raporu gönderin,
uygunsa önceden işlenmiş kaynak ile.
Talimatlar için bakınız.

Bu kaynak dosyada özyineleme yoktur, sınıflardan birinin dolaylı olarak bile temel sınıf olduğu söylenemez. (C ++ 'ta böyle bir şablon sınıfında S<1>ve S<2>tamamen farklı sınıflardır.) Segmentasyon hatası, derleyicide özyinelemeden sonra yığın taşmasından kaynaklanır.

Bash (Tehlike Uyarısı)

while true
do 
  mkdir x
  cd x
done

Açıkça söylemek gerekirse, bu doğrudan taşma yapmaz, ancak " sürekli akışa neden olan bir yığın oluşturma durumu " olarak etiketlenebilecek olanı oluşturur : bunu diskiniz doluncaya kadar çalıştırdığınızda ve karışıklığı kaldırmak istediğinizde "rm -rf x ", bu çarptı.

Yine de, tüm sistemlerde gerçekleşmez. Bazıları diğerlerinden daha sağlam.

Büyük tehlike UYARI:

Bazı sistemler bunu çok fena şekilde ele alır ve temizlik için çok zaman harcayabilirsiniz (çünkü "rm -rf" kendiliğinden bir problemle karşılaşacaktır). Temizlemek için benzer bir komut dosyası yazmanız gerekebilir.

Emin değilseniz çizik bir VM'de bunu daha iyi deneyin.

Not: Aynı şey, bir toplu komut dosyasında programlanmış veya yapılmışsa da geçerlidir.
PPS: Sizden bir yorum almak, sisteminizin nasıl çalıştığını yorumlamak ...

Java

Java Puzzlers'dan hoş bir kitap . Ne yazdırıyor?

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

Bir StackOverflowError ile başarısız oluyor.

Yapıcıdaki istisna, sadece kırmızı bir ringa balığı. Kitabın bu konuda söylediği şey bu:

Bir yapıcı çağırdığınızda, example değişken başlatıcıları , yapıcının gövdesinden önce çalışır . Bu durumda, değişken için başlatıcı, internalInstanceyapıcıyı yinelemeli olarak çağırır. Bu yapıcı, sırayla, internalInstanceisteksiz kurucuyu tekrar ve benzeri şekilde, adin sonsuz olarak çağırarak kendi alanını başlatır . Bu özyinelemeli çağrılar StackOverflowError, kurucu birimin yürütme şansını yakalamadan önce olur. Çünkü StackOverflowErrorbir alt tür Errorolduğundan Exception, catch cümlesi mainonu yakalamaz.

Lateks

\end\end

Giriş yığını taşar, çünkü burada\end açıklandığı gibi sürekli olarak sonsuz bir döngüde kendini genişletir .

TeX, a TeX capacity exceeded, sorry [input stack size=5000]veya benzeri ile başarısız olur .

BF

Sonunda yığının üzerinden taşar, tercümanın yığını ne kadar sürdüğüne bağlıdır ...

+[>+]

C #, derleme zamanında

Microsoft C # derleyicisinin yığınını uçurmasına neden olmanın birkaç yolu vardır; C # derleyicisinden aldığınız "ifade derlemek için çok karmaşık" bir hata gördüğünüzde neredeyse kesinlikle yığının uçması nedeniyle oluşuyor.

Ayrıştırıcı özyinelemeli iniş, bu nedenle yeterince derinlemesine yuvalanmış herhangi bir dil yapıları yığını mahveder:

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

İfade ayrıştırıcısı, genellikle yinelenen taraftaki özyinelemeleri ortadan kaldırma konusunda oldukça akıllıdır. Genelde:

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

Son derece derin bir ayrıştırma ağacı oluşturan, yığını üflemeyecek. Fakat özyinelemeyi diğer tarafta olmaya zorlarsanız:

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

sonra yığın üflenebilir.

Bunlar, programın çok büyük olması, inelegant özelliğine sahiptir. Ayrıca semantik analizörün küçük bir programla sınırlandırılmamış özyinelemelere girmesi de mümkündür, çünkü tip sistemdeki bazı garip döngüleri ortadan kaldıracak kadar akıllı değildir. (Roslyn bunu geliştirebilir.)

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? 

Bu analizin neden sonsuz bir özyinelemeye girdiğini anlatıyorum:

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

ve daha birçok ilginç örnek için bu makaleyi okumalısınız:

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

İnternette (milyar kişi / gün tarafından kullanılır)

Redirects, HTTP status code: 301

Örneğin, Dell destek web sitesinde (alınma, özür dilerim Dell):

Destek TAG’sini URL’den kaldırırsanız, sonsuz yönlendirmelere girilir . Aşağıdaki URL’de ######, herhangi bir destek TAG’ıdır.

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

Yığın taşmasına eşdeğer olduğuna inanıyorum.

PHP

Yalnızca döngü öğeleriyle yapılan bir yığın akışı.

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

Açıklama (spoiler görmek için hover):

Tercüman, çöpü $tmpdiziyi toplamaya çalıştığında ( $tmpburada yeniden atama yaparken ) program farklılaşacaktır . Sırf dizinin çok derin olması (kendi kendine referans) ve çöp toplayıcı bir özyinelemeyle sonuçlanır.

Java

Tam tersini yaptım - açıkça bir yığın taşma hatası atması gereken, ancak yapmayan bir program.

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

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

İpucu: program O (2 ⁿ ) sürede çalışır ve n yığının boyutudur (genellikle 1024).

Gönderen Java puzzlers # 45:

En makinemiz 10 yürütebileceği düşünelim ¹⁰ saniyede görüşmeleri ve 10 oluşturmak ¹⁰ akım standartlarına göre oldukça cömert saniyede istisnalar. Bu varsayımlara göre, program yaklaşık 1.7 × 10 ²⁹¹ yıl içinde sona erecektir . Bu perspektif koymak için, bizim güneşin ömrü 10 olarak tahmin ediliyor ¹⁰ yıldır, bu yüzden hiçbirimiz bu program sona görmeye etrafında olacak bir sakınca yoktur. Sonsuz bir döngü olmasa da, olabilir.

C #

İlk gönderi, lütfen beni rahatça takip edin.

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

Bu basitçe bir yığın izlemesi yaratır, üst kareyi alır (bu bizim son çağrımız olacak Main()), yöntemi alır ve onu çağırır.

Java

• Java 5'te, printStackTrace()sonsuz bir döngüye girer.
• Java 6'da, printStackTrace()atar StackOverflowError.
• Java 7 ve 8'de düzeltildi.

Çılgınca olan şey, Java 5 ve 6'da kullanıcı kodundan gelmemesi, JDK kodunda gerçekleşmesi. Kimse printStackTrace(), yürütülmesi tehlikeli olabileceğinden şüphelenmiyor .

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: Özyinelemeli olmayan, tekrarlamalı fonksiyon mutasyonu

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

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

Burada hiçbir özyineleme yok. tek bir işlev çağrısındaf yığının dışına taşana kadar sürekli ve daha fazla argüman ile tekrar tekrar körüklenecektir . console.logBölüm durumda bunu yapmak için kaç argüman görmek istiyorum isteğe bağlıdır. Ayrıca akıllı JS motorlarının bunu optimize etmemesini sağlar.

CoffeeScript'te kod-golf sürümü, 28 karakter:

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

Destansı bir başarısızlıkla 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());
    }
}

Başarısızlık şekli epik, aklımı başımdan aldı:

Bu görünüşte sonsuz görünen bir tuhaf resim dizisinin sadece bir karesidir.

Bu şimdiye kadarki en garip şey olmalı. Herhangi biri açıklayabilir mi? Görünüşe göre, girinti için kullanılan sürekli artan boşluk, bu beyaz blokların görünmesine neden olmaktadır. Win7 Enterprise x64'te .NET 4.5 ile gerçekleşir.

Aslında henüz sonunu görmedim. Eğer değiştirirseniz System.Console.Outile System.IO.Stream.Null, oldukça hızlı ölür.

Açıklama oldukça basittir. Tek bir özelliğe sahip bir sınıf yapıyorum ve her zaman içerdiği türün yeni bir örneğini döndürür. Bu yüzden sonsuz derinlikte bir nesne hiyerarşisi. Şimdi bunu okumaya çalışan bir şeye ihtiyacımız var. Kullandığım XmlSerializeryer orası. Ve görünüşe göre, özyinelemeyi kullanır.

darbe

_(){ _;};_

Birçoğu özyinelemenin açık olduğunu kabul etse de , oldukça iyi görünüyor. Hayır?

Yürütme sonrasında şunları görmeniz garanti edilir:

Segmentation fault (core dumped)

Haskell

(üzgün ama gerçek en azından ghc-7.6, gerçi O1ya da daha fazlası ile sorunu ortadan kaldıracak olsa bile )

main = print $ sum [1 .. 100000000]

Smalltalk

Bu, anında yeni bir yöntem oluşturur, anında
  yeni bir yöntem oluşturur, anında
    yeni bir yöntem oluşturur, bu da
      ...
    ...
  ..
ve sonra ona aktarılır.

Ekstra küçük bir baharat, hem daha uzun hem de daha uzun bir yöntem adı ve aynı zamanda delikten düştüğümüzde alıcı olarak büyük bir sayı yaratarak yığın hafızasını VE yığın belleği aynı anda zorlamaktan gelir ... ).

Tamsayı içinde derleme:

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.

sonra zıplayarak, değerlendirerek "2 downTheRabbitHole"...
... bir süre sonra, bir RecursionException'ı gösteren bir hata ayıklayıcısına sahip olacaksınız.

O zaman tüm pisliği temizlemelisiniz (hem SmallInteger hem de LargeInteger artık pek çok harikalar diyarı koduna sahip):

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

ya da tarayıcıda biraz zaman harcayarak Alice'in harikalar diyarını kaldırabilirsiniz.

İşte iz başından bazıları:

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

Not: daha sonra Smalltalk'ın kalıcı değişiklik günlüğü dosyasını temizlemek zorunda kalmamak için "withoutUpdatingChangesFile:" eklendi.

PPS: meydan okuma için teşekkürler: yeni ve yenilikçi bir şeyler düşünmek eğlenceliydi!

PPPS: Bazı Smalltalk lehçelerinin / sürümlerinin taşan yığın karelerini yığına kopyaladığını - bu nedenle bunun yerine yetersiz bellek durumuna yol açabileceğini unutmayın.

C #

Gerçekten büyük struct, özyineleme yok, saf C #, güvensiz kod değil.

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

bir vurucu olarak bunu belirten hata ayıklama pencereleri çöküyor {Cannot evaluate expression because the current thread is in a stack overflow state.}

Ve genel sürüm (NPSF3000 önerisi için teşekkürler)

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 #

Geçersiz kılınan ==operatörün hatalı uygulaması :

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

Birisi operator==, ==operatörü kullanarak kendisini aramanın açık olduğunu söyleyebilir , ancak genellikle böyle düşünmüyorsunuz ==, bu yüzden bu tuzağa düşmek kolaydır.

SnakeYAML kullanarak cevap vermeye başlamak

class A
{

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

Düzenleme: ungolfed onu

Bunun nasıl çalıştığını öğrenmek okuyucuya kalmış: P (tip: stackoverflow.com)

Bu arada: özyineleme SnakeYAML tarafından dinamik olarak yapılır (serileştirdiği alanları nasıl algıladığını bilir ve Pointkaynak koduna bakarsanız fark edeceksiniz )

Düzenleme: Bunun nasıl çalıştığını söylemek:

SnakeYAML , aynı adı taşıyan bir çift getXXXve mthod arar ve alıcı türünün geri dönüş türü, ayarlayıcının parametresiyle aynıdır; ve şaşırtıcı bir şekilde sınıf sahiptir ve kendisi döndürür; SnakeYAML bunu fark etmiyor ve bu ilginç ve StackOverflow'ları tekrar ediyor. İçinde onlarla çalışırken ve üzerinde stackoverflow.com'u sorurken bunu keşfetti.setXXXXXXPointPoint getLocation()void setLocation(Point P)HashMap

C #

yanlış uygulanmış mülk alıcı

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

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