Как программист, вы наверняка знаете ошибку переполнения стека из-за очевидной рекурсии. Но, конечно, есть много странных и необычных способов заставить ваш любимый язык выплюнуть эту ошибку.

Цели:

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 32bit

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

Если вы хотите убить свой браузер, попробуйте это в консоли.

Ява

Видел что-то вроде этого где-то здесь:

Изменить: нашел, где я видел это: ответ Джо К. на самую короткую программу, которая выдает ошибку 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

С

Вполне легко:

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()бросок StackOverflowError. printStackTrace()обычно используется для отладки и регистрации, и никто не подозревает, что это может быть опасно. Нетрудно понять, что этот код может быть использован для создания серьезных проблем безопасности:

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-deep = 40000
g ++: внутренняя ошибка компилятора: ошибка сегментации (программа cc1plus)
Пожалуйста, отправьте полный отчет об ошибке,
с предварительно обработанным источником, если это необходимо.
Смотрите инструкции.

В этом исходном файле нет рекурсии, ни один из классов не является базовым, даже косвенно. (В C ++ в шаблонном классе, как этот, S<1>и S<2>есть совершенно разные классы.) Ошибка сегментации происходит из-за переполнения стека после рекурсии в компиляторе.

Bash (Оповещение об опасности)

while true
do 
  mkdir x
  cd x
done

Строго говоря, это не приведет к прямому переполнению стека, но генерирует то, что может быть помечено как « ситуация генерирования постоянного стека- переполнения »: когда вы запускаете это, пока ваш диск не заполнен, и хотите удалить беспорядок с помощью «rm -rf» х ", тот поражен.

Это происходит не во всех системах. Некоторые из них более устойчивы, чем другие.

Большая опасность ВНИМАНИЕ:

некоторые системы справляются с этим очень плохо, и вам может быть очень трудно очистить (потому что сам «rm -rf» столкнется с проблемой повторного использования). Возможно, вам придется написать аналогичный скрипт для очистки.

Лучше попробуй это на виртуальной машине, если не уверен.

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.

Исключением в конструкторе является просто красная сельдь. Вот что говорит об этом книга:

Когда вы вызываете конструктор, инициализаторы переменных экземпляра запускаются перед телом конструктора . В этом случае инициализатор для переменной internalInstanceрекурсивно вызывает конструктор. Этот конструктор, в свою очередь, инициализирует свое собственное internalInstanceполе, снова вызывая конструктор Reluctant и так далее, до бесконечности. Эти рекурсивные вызовы приводят к тому, StackOverflowErrorчто тело конструктора получает возможность выполнить. Поскольку StackOverflowErrorэто подтип, Errorа не Exceptionусловие maincatch, оно не улавливает его.

Латекс

\end\end

Стек ввода переполняется, потому что \endмногократно расширяется в бесконечном цикле, как описано здесь .

TeX терпит неудачу с TeX capacity exceeded, sorry [input stack size=5000]или подобным.

BF

В конечном итоге переполнит стек, зависит только от того, как долго интерпретатор делает стек ...

+[>+]

C #, во время компиляции

Есть несколько способов заставить компилятор Microsoft C # взорвать свой стек; всякий раз, когда вы видите «выражение слишком сложное, чтобы скомпилировать» ошибку компилятора C #, что почти наверняка потому, что стек перегорел.

Синтаксический анализатор имеет рекурсивное происхождение, поэтому любые достаточно глубоко вложенные языковые структуры будут уничтожать стек:

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

Анализатор выражений довольно умен в устранении рекурсий на стороне, которая обычно рекурсивна. Обычно:

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

который строит чрезвычайно глубокое дерево разбора, не взорвет стек. Но если вы заставите рекурсию произойти на другой стороне:

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

тогда стек может быть взорван.

У них есть неимоверное свойство, что программа очень большая. Также можно заставить семантический анализатор переходить в неограниченную рекурсию с помощью небольшой программы, потому что он недостаточно умен, чтобы удалять определенные странные циклы в системе типов. (Рослин может улучшить это.)

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):

Если вы удалите тег поддержки из 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() вводится бесконечный цикл.
• В яве 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будет многократно каррироваться с большим количеством аргументов, пока не переполнит стек за один вызов функции. 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]

Болтовня

Это создает новый метод на лету, который
  создает новый метод на лету, который
    создает новый метод на лету, который
      ...
    ...
  ..
и затем передает ему.

Дополнительная небольшая специя возникает из-за одновременной нагрузки на стековую память и кучную память путем создания более длинного и длинного имени метода и огромного числа в качестве получателя, когда мы падаем в дыру ... (но рекурсия поражает нас первой ).

скомпилировать в 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.

затем перейдите, оценивая "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 #

Неправильная реализация переопределенного ==оператора:

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

Отредактируйте

Это до читателя, чтобы узнать, как это работает: P (tip: stackoverflow.com)

Кстати: рекурсия динамически выполняется SnakeYAML (вы заметите, если знаете, как он обнаруживает поля, которые он сериализует, и посмотрите в исходном коде России Point)

Редактировать: рассказывая, как это работает:

SnakeYAML ищет пару getXXXи setXXXmthod с тем же именем, XXXи тип возвращаемого значения получателя совпадает с параметром установщика; и удивительно, что у 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;
}