프로그래머는 명백한 재귀로 인한 스택 오버플로의 오류를 확실히 알고 있습니다. 그러나 좋아하는 언어가 그 오류를 뱉어내는 데 이상하고 특이한 방법이 많이 있습니다.

목표 :

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 / 리눅스 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시점으로 돌아갑니다 . 반송 주소가 스택에 있지만 조정이 필요할 수있는 모든 플랫폼에서 작동합니다.mainf

물론, 배열 외부에 쓰는 것은 정의되지 않은 동작 이며, 콧수염을 파란색으로 칠하는 것보다 스택 오버플로를 일으킬 것이라는 보장은 없습니다. 플랫폼, 컴파일러 및 컴파일 플래그의 세부 사항은 큰 차이를 만들 수 있습니다.

자바 스크립트 / DOM

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

    title = 'Kill me!';
}

브라우저를 죽이려면 콘솔에서 시도하십시오.

자바

여기 어딘가에 이와 같은 것을 보았습니다.

편집 : 내가 본 곳을 찾았습니다 : StackOverflow Error 를 발생시키는 가장 짧은 프로그램에 대한 Joe K의 답변

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

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

일부 Java 초보자는 혼동 될 수 있습니다. 재귀 호출을 숨 깁니다. String 이기 때문에 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. 매개 변수를 각 호출에 대해 스택으로 푸시하지만 아무 것도 표시하지 않습니다. 스택 채우기.

자바 스크립트

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. 재귀는 JDK의 일반적으로 의심되지 않는 printStackTrace()동작과 예외를 검사하는 데 사용되는 디버깅 및 로깅을위한 타사 라이브러리 내에 있습니다. 또한 예외가 발생하는 장소는 예외가 처리 된 장소와 매우 거리가 먼 것 같습니다.

어쨌든, 여기에 a를 던지고 StackOverflowError재귀 적 인 메소드 호출이 포함되지 않은 코드가 있습니다. 은 StackOverflowError외부 일 mainJDK의에서, 방법 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"

리눅스 x86 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

스포일러:

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>완전히 별개의 클래스이다.) 세그멘테이션 폴트 컴파일러 재귀 후 스택 오버 플로우에 기인한다.

배쉬 (위험 경고)

while true
do 
  mkdir x
  cd x
done

엄밀히 말하면 오버플로를 직접 스택하지는 않지만 " 지속적인 스택 오버 플로우 생성 상황 " 합니다. 디스크가 가득 찰 때까지이를 실행하고 "rm -rf x ", 그 중 하나가 맞았습니다.

그러나 모든 시스템에서 발생하는 것은 아닙니다. 일부는 다른 것보다 강력합니다.

큰 위험 경고 :

어떤 시스템은 이것을 아주 잘 처리합니다 잘못 하므로 정리하기가 매우 어려울 수 있습니다 ( "rm -rf"자체가 recusion 문제가 발생하기 때문에). 정리를 위해 비슷한 스크립트를 작성해야 할 수도 있습니다.

확실하지 않으면 스크래치 VM에서이 방법을 사용하는 것이 좋습니다.

추신 : 물론 배치 스크립트로 프로그래밍하거나 수행하는 경우에도 마찬가지입니다.
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가 생성자를 재귀 적으로 호출합니다. 그 생성자는 차례로 internalInstanceReluctant 생성자 등을 다시 호출하여 자체 필드를 초기화합니다 . 이러한 재귀 호출로 인해 StackOverflowError생성자 본문이 실행될 기회를 얻습니다. StackOverflowError가 Error아닌 의 하위 유형 이므로 Exceptioncatch 절이 catch main하지 않습니다.

유액

\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))))))))))))))))))))))))))))))))))))))))))...;

그런 다음 스택을 날릴 수 있습니다.

이것들은 프로그램이 매우 크다는 우아한 특성을 가지고 있습니다. 또한 시맨틱 분석기가 작은 시스템으로 무한한 재귀로 들어가는 것이 가능합니다. 유형 시스템에서 특정 홀수주기를 제거하기에 충분히 영리하지 않기 때문입니다. (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 죄송)

URL에서 지원 TAG를 제거하면 무한 리디렉션됩니다 . 다음 URL에서 ######은 지원되는 TAG입니다.

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여기에서 재 할당 할 때) 프로그램은 segfault 입니다. 배열이 너무 깊어서 (자체 참조) 가비지 수집기가 재귀로 끝납니다.

자바

나는 분명히 스택 오버플로 오류를 발생시켜야하지만 그렇지 않은 프로그램과 정반대를했습니다.

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

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

힌트 : 프로그램은 O (2 ⁿ ) 시간에 실행되며 n 은 스택 크기 (일반적으로 1024)입니다.

에서 자바 퍼즐 러 (Puzzler) # 45 :

우리 기계 가 초당 10 ¹⁰ 호출을 실행 하고 초당 10 ¹⁰ 예외를 생성 할 수 있다고 가정합시다 . 이는 현재 표준에 따라 상당히 관대합니다. 이러한 가정하에 프로그램은 약 1.7 × 10 ²⁹¹ 년 후에 종료됩니다 . 이 관점에서 태양의 수명은 10 ¹⁰ 년으로 추정 되므로이 프로그램이 끝나는 사람은 아무도 없을 것입니다. 무한 루프는 아니지만 그럴 수도 있습니다.

씨#

첫 번째 게시물이므로 나에게 쉽게 가십시오.

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

자바 스크립트 : 비 재귀, 반복 함수 돌연변이

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

그것이 실패하는 방식은 서사시이며, 내 마음이 완전히 불었습니다.

그것은 겉보기에는 무한대로 넘어지는 일련의 이상한 이미지의 한 프레임에 불과합니다.

이것은 가장 이상한 일이되어야합니다. 아무도 설명 할 수 있습니까? 분명히 들여 쓰기에 사용되는 공간이 계속 늘어 나면 흰색 블록이 나타납니다. .NET 4.5가 설치된 Win7 Enterprise x64에서 발생합니다.

나는 실제로 아직 끝을 보지 못했습니다. 당신이 바꿀 경우 System.Console.Out에 System.IO.Stream.Null, 그것은 꽤 빨리 죽는다.

설명은 매우 간단합니다. 단일 속성을 가진 클래스를 만들고 항상 포함 유형의 새 인스턴스를 반환합니다. 그래서 그것은 무한히 깊은 객체 계층입니다. 이제 우리는 그것을 통해 읽을 수있는 무언가가 필요합니다. 그것이 내가 사용하는 곳 XmlSerializer입니다. 분명히 재귀를 사용합니다.

세게 때리다

_(){ _;};_

많은 사람들이 재귀가 명백 하다는 것을 인식 할 수는 있지만 꽤 좋아 보입니다. 아니?

실행하면 다음을 볼 수 있습니다.

Segmentation fault (core dumped)

하스켈

(슬프지만 사실까지 적어도 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...

추신 : 스몰 토크의 지속적인 변경 로그 파일을 나중에 정리할 필요가 없도록 "withoutUpdatingChangesFile :"이 추가되었습니다.

PPS : 도전에 대한 감사 : 새롭고 혁신적인 무언가에 대해 생각하는 것이 재미있었습니다!

PPPS : 일부 스몰 토크 방언 / 버전은 넘쳐나는 스택 프레임을 힙에 복사하므로 메모리 부족 상황이 발생할 수 있습니다.

씨#

정말 크고 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>>>>();
    }
}

씨#

재정의 ==연산자 의 잘못된 구현 :

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 it

그것이 어떻게 작동하는지 알아내는 것은 독자에게 달려 있습니다. : P (tip : stackoverflow.com)

그건 그렇고 : 재귀는 SnakeYAML에 의해 동적으로 이루어집니다 (직렬화 된 필드를 어떻게 감지하고 Point소스 코드 에서보고하는지 알 수 있습니다 )

편집 : 작동 방식을 알려줍니다.

SnakeYAML은 쌍을 찾는다 getXXX및 setXXX대한 동일한 이름 mthod XXX게터의 타입의 파라미터 설정 부와 동일 리턴; 그리고 놀랍게도 Point클래스에는 Point getLocation()and void setLocation(Point P)가 있습니다. SnakeYAML은이를 인식하지 못하고 해당 문제와 StackOverflow에서 반복됩니다. 내부에서 그들과 함께 일하고 HashMapstackoverflow.com에 요청할 때 하나를 발견 했습니다.

씨#

잘못 구현 된 속성 게터

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

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