Sụp đổ trình biên dịch yêu thích của bạn [đã đóng]


44

Viết một mã hợp pháp hoàn hảo bằng một ngôn ngữ phù hợp với sự lựa chọn của bạn mà trình biên dịch sẽ làm sập trình biên dịch hoặc gửi nó vào một vòng lặp vô hạn (thời gian biên dịch vô hạn).

Những hạn chế:

  • Sử dụng một ngôn ngữ tiêu chuẩn được sử dụng trong thế giới thực.
  • Sử dụng một trình biên dịch chuẩn, được phát triển tốt (không có câu trả lời nào như "Tôi đã viết trình biên dịch C của mình bị sập trên mọi thứ").
  • Mã phải hợp pháp trong ngôn ngữ (vì vậy rất có thể bạn sẽ phải khai thác trình biên dịch hoặc lỗi ngôn ngữ).
  • Cung cấp phiên bản trình biên dịch và các tùy chọn được sử dụng để người khác có thể sao chép nó.
  • Giải thích tại sao trình biên dịch bị sập, nếu có thể.

Chúc vui vẻ :)


4
Bạn có thể giải thích những gì bạn có nghĩa là "tai nạn"?
Ông Llama

@GigaWatt Ý tôi là trình biên dịch dừng lại một cách không định hướng. Không bằng cách biên dịch thành công đầu vào cũng như bằng cách đưa ra một thông báo lỗi. Nó phải thực sự sụp đổ, như segfault , ăn hết bộ nhớ, ném ngoại lệ không được kiểm soát, v.v.
Petr Pudlák

1
Cuộc thi này chủ yếu chỉ là một bài tập tìm kiếm các báo cáo lỗi cho các trường hợp thử nghiệm: /
Sparr

1
Là sụp đổ một thông dịch viên được phép?
Đánh dấu

1
Bình chọn để mở lại!
noɥʇʎԀʎzɐɹƆ

Câu trả lời:


21

Tôi khá chắc chắn rằng nó đã được sửa bây giờ, nhưng trước đây bạn có thể làm hỏng trình biên dịch Java (hoặc, làm hỏng Eclipse) bằng cách viết

class Foo {
  static double d = 2.2250738585072012e-308;
}

http://www.exploringbinary.com/java-hangs-when-converting-2-2250738585072012e-308/

Trên thực tế, theo trang đó, trình biên dịch sẽ chỉ bị treo chứ không bị sập. Tuy nhiên, tôi nghĩ rằng đó là khá vui vẻ.


48

Giải pháp yêu thích của tôi cho GHC:

data Bad a = C (Bad a -> a)

xx :: Bad a -> a
xx (x@(C x')) = x' x

omega :: a
omega = xx (C xx)

main = omega

Đối với GHC 6.12.1 cả ghci Bad.hsghc Bad.hsvòng lặp vô hạn. Vòng lặp GHC 7.4.1 vô hạn khi ghc -O2 Bad.hsđược thực thi.

Giải thích: omega được định nghĩa bằng cách sử dụng đệ quy vô hạn (cách duy nhất nó có thể cư trú với bất kỳ loại nào). Trình biên dịch của trình biên dịch xem xxnhư là một hàm đơn giản, không đệ quy, vì vậy nó cố gắng định tuyến nó theo định nghĩa của omega. Nó dẫn đến kết quả (\x@(C x') -> x' x) (C xx). Nhìn thấy một mô hình khớp trên một hàm tạo, trình biên dịch sẽ cố gắng giảm nó, lấy xx (C xx)lại và các vòng lặp. Thủ thuật là xxthực sự đệ quy, nhưng đệ quy được ẩn trong kiểu dữ liệu.

Lưu ý: Trong khi viết câu đố, tôi quên rằng tôi đã để GHC chạy trong vòng lặp vô hạn. Nó chiếm hết bộ nhớ của tôi, làm sập Firefox và tôi hầu như không thể giết được nó mà không cần thiết lập lại.


5
+1 chỉ cho những rắc rối bạn gặp phải cho câu trả lời: P
UnkwnTech

4
@UnkwnTech :-) Thật ra tôi đã phát hiện ra điều này một cách tình cờ khi cố gắng thực hiện đệ quy chỉ sử dụng kiểu dữ liệu đệ quy.
Petr Pudlák

18

Điều này là dễ dàng trong bất kỳ ngôn ngữ gõ phụ thuộc . Việc kiểm tra loại phụ thuộc chung là không thể áp dụng được vì nó có thể yêu cầu tính toán phức tạp tùy ý (Turing-Complete). Bạn chỉ có thể mã hóa trong một loại phụ thuộc một giá trị quá lớn. Sau đó, trình kiểm tra loại sẽ sử dụng tất cả bộ nhớ có sẵn và sự cố. Chẳng hạn, trong Coq, ReyCharles đưa ra ví dụ vềCompute 70000. , điều này khiến trình kiểm tra kiểu tạo ra một số Peano khổng lồ và sự cố.

Trong các ngôn ngữ phổ biến hơn hỗ trợ một số loại mở rộng macro hoặc siêu lập trình, bạn có thể làm điều gì đó tương tự. Ví dụ: bạn có thể sử dụng tất cả bộ nhớ khả dụng trong C:

#include <stdio.h>
#define a printf("%s", "Hello, world!\n");
#define b a a a a a a a a a a a a a a a a
#define c b b b b b b b b b b b b b b b b
#define d c c c c c c c c c c c c c c c c
#define e d d d d d d d d d d d d d d d d
#define f e e e e e e e e e e e e e e e e
// ...
#define z y y y y y y y y y y y y y y y y
int main() { z }

Ngôn ngữ lập trình D cho phép thực thi chức năng thời gian biên dịch . Điều này có thể được sử dụng để tính toán một cái gì đó tại thời gian biên dịch quá lớn để phù hợp với bộ nhớ. Một cái gì đó tương tự có thể đạt được bằng cách sử dụng siêu lập trình mẫu C ++.

Trong XML (không phải là ngôn ngữ lập trình được biên dịch, nhưng bộ xử lý XML tương tự như trình biên dịch), việc mở rộng các thực thể có thể làm cho bộ xử lý hết bộ nhớ:

<?xml version="1.0"?>
<!DOCTYPE lolz [
 <!ENTITY lol "lol">
 <!ENTITY lol1 "&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;">
 <!ENTITY lol2 "&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;">
 <!ENTITY lol3 "&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;">
...
]>
<lolz>&lol999;</lolz>

Đây được gọi là cuộc tấn công tỷ tỷ cười .


4
Lưu ý <lolz>&lol999;</lolz>là 10 ^ 999 cười, không phải là tỷ. Các tài liệu tham khảo được liên kết sử dụng <lolz>&lol9;</lolz>, mà thực sự là một tỷ.
mbomb007

Lưu ý rằng vấn đề Coq không liên quan gì đến tính đầy đủ của Turing; Hệ thống loại của Coq được thiết kế đặc biệt để việc kiểm tra loại thể quyết định và không hoàn thành Turing. Việc kiểm tra kiểu sẽ luôn khả thi với một lượng bộ nhớ không đổi (và nó sẽ luôn chấm dứt), nhưng hằng số đó phụ thuộc vào mã được đề cập và có thể được tạo ra tùy ý lớn.
John Colanduoni

18

C #

Tìm thấy điều này trên một câu hỏi stackoverflow :

using System;
using System.Linq;

public class Test
{
    public static void Main()
    {
        Enumerable.Range(0, 1).Sum(a =>
        Enumerable.Range(0, 1).Sum(b =>
        Enumerable.Range(0, 1).Sum(c =>
        Enumerable.Range(0, 1).Sum(d =>
        Enumerable.Range(0, 1).Sum(e =>
        Enumerable.Range(0, 1).Sum(f =>
        Enumerable.Range(0, 1).Count(g => true)))))));
    }
}

Trình biên dịch cuối cùng sẽ sụp đổ.

Vấn đề dường như liên quan đến suy luận kiểu và / hoặc thế hệ lambda kết hợp với độ phân giải quá tải.


13
+1 để làm cho intellisense của Visual Studio tiêu thụ tất cả bộ nhớ khả dụng và làm sập IDE. Đây là một trò đùa tôi sẽ chỉ sử dụng cho sức mạnh của tốt.
Đánh dấu

15

VBA

Nếu bạn có thể làm sập IDE bằng cách gõ mã thì sao?

trong bất kỳ ứng dụng Microsoft Office nào, hãy thử điều này:

ALT+ F11để đến cửa sổ VBA, sau đó thử đoạn mã sau

sub foo()
dim v(1 to 3, 1 to 3)
redim preserve v(,1 to 5)

và kìa

Cái chết của Excel

Bạn có thể chỉ cần gõ redim preserve v(,1 to 5)vào cửa sổ ngay lập tức, và nó sẽ sụp đổ sau khi bạn nhấn ENTER!


hay, nhưng giống như "đánh sập trình thông dịch yêu thích của bạn"
mbx

Tôi có thể nhận được một bản tóm tắt nhanh chóng về lý do tại sao điều này hoạt động?
Ông Llama

1
@GigaWatt, nó được thảo luận sâu hơn một chút ở đây , nhưng có vẻ như IDE không thể đối phó với các lỗi (biểu tượng không mong đợi ,và dự kiến ,)
SeanC

6

Perl (15)

BEGIN{1while 1}

Điều này tạo ra một vòng lặp vô hạn tại thời gian biên dịch :

Một khối mã BEGIN được thực thi càng sớm càng tốt, đó là thời điểm nó được xác định hoàn toàn, ngay cả trước khi phần còn lại của tệp chứa (hoặc chuỗi) được phân tích cú pháp.

(từ perlmod )

Và đó là lý do tại sao Perl không thể hoàn thành phân tích mã. Điều này không chấm dứt:

$ perl -MO=Deparse -e 'BEGIN{1while 1}'

5

J

Điều này phân biệt trình thông dịch J (ít nhất là trên Linux):

15!:1[3#2

Nó cố đọc từ địa chỉ bộ nhớ 2. Thật thú vị, nếu bạn thử bằng 0 hoặc 1, bạn sẽ nhận được domain error.


5

TeX

\def\x{\x}\x

TeX là một ngôn ngữ mở rộng vĩ mô. Ở đây, chúng tôi xác định việc mở rộng macro \xtrở \xlại, và sau đó chúng tôi thêm vào sau đó là một lời gọi \x. TeX bị kẹt vô tận thay thế \xbằng \x.


2
Lưu ý: đây không phải là cách ngắn nhất để đạt được điều này. TeX có một khái niệm về "các ký tự hoạt động", về cơ bản là các ký tự được coi là tên macro. Vì vậy, bạn có thể cạo 3 ký tự từ này.
Hammerite

5

Kế hoạch

(define-syntax s
    (syntax-rules ()
        ((_ (t) ...) (s (t t) ... (t t) ...))
        ((_ (t u) ...) (s (t) ... (u) ...))))
(s (+))

Trình biên dịch của tôi, Chicken, đã phạm sai lầm khi cố gắng mở rộng các macro tại thời gian biên dịch cho "hiệu suất thời gian chạy" hoặc một cái gì đó. Vì vậy, nó đã trả giá của việc mở rộng này. Tôi đã đọc R5RS. Không ai nói macro phải được mở rộng tại thời điểm biên dịch.

Về cơ bản những gì đang diễn ra là macro mở rộng thành một biểu thức có kích thước vô hạn, liên tục tăng gấp đôi kích thước. Vâng, để được kỹ thuật, tăng gấp đôi mọi mở rộng khác. Số phận của nhà soạn nhạc được niêm phong. Ít nhất trên hệ thống của tôi, Gà mũ ở mức 2 GB, trong một thời gian dài cố gắng thu gom rác, sau đó gặp sự cố sau khi người thu gom rác bỏ cuộc. Mặc dù phải mất một thời gian vì tất cả các phép thuật vệ sinh đắt tiền được tính toán xảy ra.

Chuyển đổi giữa các biểu thức của biểu mẫu

(s (+) (+) (+) (+) ....

(s (+ +) (+ +) (+ +) (+ +) ....

dường như làm tăng rất nhiều tốc độ tiêu thụ bộ nhớ so với:

(define-syntax s
    (syntax-rules ()
        ((_ t ...) (s t ... t ...))))
(s +)

Tôi nghi ngờ Chicken là một trình biên dịch khá khó, có một số cách để tránh phân tích sâu các biểu thức cú pháp khi nó có thể thoát khỏi nó, nhưng giải pháp cuối cùng của tôi buộc trình so khớp mẫu phải thực sự lặn.


Ái chà. +1 và chào mừng bạn đến với Câu đố lập trình và trao đổi mã Golf Stack. Nếu bạn cần bất kỳ sự giúp đỡ, hoặc chỉ muốn nói chuyện, vui lòng trả lời nhận xét này với @wizzwizz4.
wizzwizz4

3

Lisp thường gặp

Macro làm cho nó dễ dàng:

(defmacro loop-forever ()
  (loop for x from 0 collecting x))

(defun compile-me ()
  (loop-forever))

Biên dịch compile-mecác cuộc gọi loop-forever, làm cạn kiệt bộ nhớ heap trong quá trình mở rộng của nó và làm hỏng trình biên dịch. Nếu bạn chỉ muốn làm cho trình biên dịch bị treo vô thời hạn, thì định nghĩa này loop-foreversẽ làm điều đó:

(defmacro loop-forever ()
  (loop))

Điều này sẽ hoạt động bằng cách sử dụng bất kỳ triển khai CL nào, trừ khi bạn cực kỳ thông minh và có thể phát hiện các vòng lặp vô hạn đơn giản, nhưng tôi thực sự nghi ngờ bất kỳ điều gì làm điều này. Tất nhiên bảo vệ chống lại điều này là không thể.


ồ Lisp làm cho việc viết các vòng lặp vô hạn thời gian biên dịch quá dễ dàng. Bây giờ nếu bạn thực sự đã làm hỏng trình biên dịch ...
John Dvorak

@JanDvorak Cách duy nhất để đánh sập Lisp là gọi thư viện C thông qua FFI ;-)
coredump

@coredump Vui lòng làm. Vào thời gian biên dịch :-)
John Dvorak

(defmacro loop-forever () (loop)) (defun compile-me () (loop-forever))nên là đủ Nó treo CCL cho tôi.
mẫu

3

PHP 5.3.1 (Trình thông dịch Segfaults ) ( Lỗi 50261 , đã sửa trong 5.3.3)

   lớp kiểm tra
   {
       hàm testClass ()
       {
           echo 'Chuỗi đầu ra!';
       }
   }

   lớp testClass2 mở rộng testClass
   {
       hàm __construct ()
       {
           call_user_func (mảng ('cha mẹ', '__construct'));
       }
   }

   testClass2 mới;

Đây là một vấn đề, bởi vì đoạn mã trên là phổ biến trong rất nhiều mã tôi đang làm việc, khiến đây là một vấn đề khá phổ biến đối với chúng tôi.

(Nếu tôi nhớ lại một cách chính xác, tại một thời điểm, đây là cách duy nhất để gọi các hàm tạo cha mẹ trong PHP.)


3

CƯỜI MỞ MIỆNG

(Trình biên dịch DMD32 D v2.067.1, bản dựng Windows)

enum x = "mixin(x);";
mixin(x);

Lưu ý rằng điều này sẽ gửi trình biên dịch vào một vòng lặp vô hạn sụp đổ nó.

Lỗi: hết bộ nhớ

Ốc cơ học cho rằng các tính năng lập trình thời gian biên dịch trong D có thể bị lạm dụng cho mục đích này, nhưng giải pháp có lẽ đơn giản hơn loại kỹ thuật mà anh ta có trong đầu.


Đối với những người không quen thuộc với 'chuỗi mixins', đây là một tính năng macro khá đơn giản. Khi trình biên dịch gặp phải mixin("asdf"), nó sẽ thay thế nó bằng nội dung của chuỗi asdfvà cố gắng biên dịch lại.

Giải pháp trên sẽ được mở rộng như:

mixin(x);  ->  mixin("mixin(x);");  ->  mixin(x);

Vì vậy, trừ khi trình biên dịch cố gắng phát hiện trường hợp mở rộng này đến cùng, nó sẽ nhập một vòng mở rộng vô hạn.


3

Perl

Điều này xác định quá tải toán tử tại thời gian biên dịch và chạy mã tại thời gian biên dịch để thêm các thể hiện của lớp lại với nhau.

(nhân tiện, thông thường đệ quy vô hạn sẽ ăn hết bộ nhớ, nhưng với tình trạng quá tải, nó chỉ bị hỏng)

package MyAmazingClass;
use 5.010;

use overload '+' => sub {
    my ($first, $second) = @_;
    return $first + $second;
};

sub new {
    my $self = shift;
    return bless {}, $self;
}

# BEGIN runs code at compile time
BEGIN {
    my $instance = MyAmazingClass->new;
    my $sum = $instance + $instance;
    say $sum;
}

Đầu ra:

fish: Job 1, 'perl' terminated by signal SIGSEGV (Address boundary error)

3

Simplex v.0.5 , 2 byte

Quá tệ, đây không phải là :

2Q

Hãy để tôi giải thích. Từ các tài liệu:

[ Q] Thêm mã nguồn chương trình vào chương trình bên ngoài, ngay từ đầu (không bao gồm! Ký tự, nếu byte hiện tại không bằng 0) Nếu byte là 2, cũng sẽ sao chép lệnh hiện tại.

Vì thế:

2 ~~ Manhattan adds 2 to the current byte: 10*0 + 2 = 2.
Q ~~ Adds program source code to the outer program, with Q

Chương trình bên ngoài là một tính năng nhỏ gọn trong Simplex: nó được đánh giá ở cuối chương trình. Vì vậy, nếu chúng tôi theo dõi ...:

P1  P2  P3  P4  ...
2Q->2Q->2Q->2Q->...

Cuối cùng, bộ nhớ sẽ hết và thế giới sẽ kết thúc.


3

Tiếng leng keng

Tôi chỉ gặp phải lỗi thú vị này.

#include <iostream>
#include <string>
#include <sstream>
#include <fstream>

std::stringstream prog;

constexpr unsigned c_strlen( char const* str, unsigned count = 0 )
{
    return ('\0' == str[0]) ? count : c_strlen(str+1, count+1);
}

template < char t_c, char... tt_c >
struct rec_eval
{
    static void eval()
    {
        rec_eval<t_c>::eval();
        rec_eval < tt_c... > :: eval ();
    }
};
template < char t_c >
struct rec_eval < t_c >
{
    static void eval() {
        switch(t_c) {
            case '+':
                prog<<"++t[i];";
                break;
            case '-':
                prog<<"--t[i];";
                break;
            case '>':
                prog<<"++i;";
                break;
            case '<':
                prog<<"--i;";
                break;
            case '[':
                prog<<"while(t[i]){";
                break;
            case ']':
                prog<<"}";
                break;
            case '.':
                prog<<"putc(t[i],stdout);";
                break;
            case ',':
                prog<<"t[i]=getchar();";
                break;
        }
    }
};

template < char... tt_c >
struct exploded_string
{
    static void eval()
    {
        rec_eval < tt_c... > :: eval();
    }
};
template < typename T_StrProvider, unsigned t_len, char... tt_c >
struct explode_impl
{
    using result =
        typename explode_impl < T_StrProvider, t_len-1,
                                T_StrProvider::str()[t_len-1],
                                tt_c... > :: result;
};

template < typename T_StrProvider, char... tt_c >
struct explode_impl < T_StrProvider, 0, tt_c... >
{
     using result = exploded_string < tt_c... >;
};

template < typename T_StrProvider >
using explode =
    typename explode_impl < T_StrProvider,
                            c_strlen(T_StrProvider::str()) > :: result;


int main(int argc, char** argv)
{
    if(argc < 2) return 1;
    prog << "#include <stdio.h>\n#include <stdlib.h>\nint main(){unsigned char* t=calloc(";
    prog << (1 << sizeof(unsigned short));
    prog << ",sizeof(unsigned short));unsigned short i=0;";

    struct my_str_provider
    {
        constexpr static char const* str() { return "++++[>+++++<-]>+++[[>+>+<<-]>++++++[<+>-]+++++++++[<++++++++++>-]>[<+>-]<-]+++>+++++++++[<+++++++++>-]>++++++[<++++++++>-]<--[>+>+<<-]>>[<<+>>-]<-->>++++[<++++++++>-]++++++++++>+++++++++[>+++++++++++<-]>[[>+>+>+<<<-]>[<+>-]>>[[>+>+<<-]>>[<<+>>-]<[<->-[<->-[<->-[<->-[<->-[<->-[<->-[<->-[<->-[<<<+>---------->->[-]]]]]]]]]]]<]<<[>>++++++++++++[<++++<++++>>-]<<[.[-]>]<<]>[<++++++[>++++++++<-]>.[-]]<<<<<.<<<<<.[<]>>>>>>>>>.<<<<<..>>>>>>>>.>>>>>>>.[>]>[>+>+<<-]>[<+>-]>[-[[-]+++++++++[<+++++++++++++>-]<--.[-]>]]<<<<<.[<]>>>>>>>>>.>>>>>>>>>.[>]<<.<<<<<.<<<..[<]>>>>>>.[>]<<.[<]>>>>>>>>>.>.[>]<<.[<]>>>>.>>>>>>>>>>>>.>>>.[>]<<.[<]>.[>]<<<<<<.<<<<<<<<<<<..[>]<<<.>.[>]>[>+>+>+<<<-]>[<+>-]>>[[>+>+<<-]>>[<<+>>-]<[<->-[<->-[<->-[<->-[<->-[<->-[<->-[<->-[<->-[<<<+>---------->->[-]]]]]]]]]]]<]<<[>>++++++++++++[<++++<++++>>-]<<[.[-]>]<<]>[<++++++[>++++++++<-]>.[-]]<<<<<.<<<<<.[<]>>>>>>>>>.<<<<<..>>>>>>>>.>>>>>>>.[>]>[>+>+<<-]>[<+>-]>[-[[-]+++++++++[<+++++++++++++>-]<--.[-]>]]<<<<<.[<]>>>>>>>>>.>>>>>>>>>.[>]<<.<<<<<.<<<..[<]>>>>>>.[>]<<<<.>>>.<<<<.<.<<<<<<<<<<.>>>>>>.[>]<<.[<]>>>>>>>>>.>.>>>>>>>>>.[>]<<.<<<<<<<.[<]>>>>>>>>>.[<]>.>>>>>>>>>.[>]<<.<<<<.<<<<<<<<<<<<<.[>]<<<<<<<<<.[>]<<.[<]>>>>>>>>.[>]<<<<<<.[<]>>>>>..[>]<<.<<<<<<<<<<<<.[<]>>>>.[>]<<.<<<<.[<]>>>>>>.>>>.<<<<<<.>>>>>>>.>>>>>>>>>>.[>]<<<.>.>>>-[>+>+>+<<<-]>[<+>-]>>[[>+>+<<-]>>[<<+>>-]<[<->-[<->-[<->-[<->-[<->-[<->-[<->-[<->-[<->-[<<<+>---------->->[-]]]]]]]]]]]<]<<[>>++++++++++++[<++++<++++>>-]<<[.[-]>]<<]>[<++++++[>++++++++<-]>.[-]]<<[>+>+<<-]>[<+>-]+>[<->[-]]<[-<<<[<]>>>>>>>>>>.<.[>]<<.[<]>>>>>>>>>>>.<<.<<<.[>]<<<<<<<<<<.[>]>>]<<<<.<<<<<.[<]>>>>>>>>>.<<<<<..>>>>>>>>.>>>>>>>.[>]>[>+>+<<-]>[<+>-]+>[<->-[<+>[-]]]<[++++++++[>+++++++++++++<-]>--.[-]<]<<<<.[<]>>>>>>>>>.>>>>>>>>>.[>]<<.<<<<<.<<<..[<]>>>>>>.[>]<<.[<]>>>>>>>>>.>.[>]<<.[<]>>>>.>>>>>>>>>>>>.>>>.[>]<<.[<]>.[>]<<<<<<.<<<<<<<<<<<..[>]<<<<.>>>..>>]"; }
    };

    auto my_str = explode < my_str_provider >{};
    my_str.eval();

    prog << "}";

    std::ofstream ofs(argv[1]);
    if(!ofs) return 2;
    ofs << prog.str() << std::endl;
    ofs.close();

    return 0;
}

Mục tiêu là dịch Brainfuck sang C, sử dụng lập trình meta mẫu để thực hiện hầu hết công việc. Mã này hoạt động cho các chương trình Brainfuck nhỏ hơn, như Hello World, nhưng khi tôi cố chạy nó với 99 Chai ...

$ clang++ -std=c++11 -fconstexpr-depth=1000 bf_static.cpp
clang: error: unable to execute command: Segmentation fault (core dumped)
clang: error: clang frontend command failed due to signal (use -v to see invocation)
clang version 3.5.2 (tags/RELEASE_352/final)
Target: i386-pc-windows-cygnus
Thread model: posix
clang: note: diagnostic msg: PLEASE submit a bug report to http://llvm.org/bugs/ and include the crash backtrace, preprocessed source, and associated run script.
clang: note: diagnostic msg:
********************

PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT:
Preprocessed source(s) and associated run script(s) are located at:
clang: note: diagnostic msg: /tmp/bf_static-afa982.cpp
clang: note: diagnostic msg: /tmp/bf_static-afa982.sh
clang: note: diagnostic msg:

********************

Nó sẽ biên dịch thành công trong GCC (sau khoảng 2 phút), nhưng liên kết nó gây ra một vấn đề khác ...

/usr/lib/gcc/i686-pc-cygwin/4.9.3/../../../../i686-pc-cygwin/bin/as: /tmp/cc0W7cJu.o: 
section .eh_frame$_ZN8rec_eval<giant mangled name removed>: string table overflow at offset 10004228
/tmp/cc3JeiMp.s: Assembler messages:
/tmp/cc3JeiMp.s: Fatal error: can't close /tmp/cc0W7cJu.o: File too big

Úi.


3

Smalltalk (Phương ngữ Squeak, phiên bản 4.x)

Rất dễ dàng, chỉ cần đánh giá điều này hoặc chấp nhận một phương pháp với nghĩa đen này

1.0e99999999999999999999

Nó sẽ cố gắng đánh giá sức mạnh của 10 trong số học Số nguyên lớn, chỉ để làm tròn chính xác inf Tsss;)

Chỉnh sửa: có bao nhiêu 9 là cần thiết?

Vì 2 ^ 10 là 1024, xấp xỉ 10 ^ 3, nên chúng ta có thể xấp xỉ 10 ^ n bằng 2 ^ (10 * n / 3). Điều đó có nghĩa là 10 ^ n yêu cầu 10 * n / 3 bit được biểu diễn dưới dạng nhị phân. Chúng tôi muốn có 10 ^ n không thể đại diện.

Giả sử con trỏ 32 bit cho bộ nhớ đối tượng, chúng ta biết rằng chúng ta không thể giải quyết nhiều hơn 2 ^ 32 byte, tức là 2 ^ 35 bit. Vì vậy, hãy đảo ngược vấn đề: 2 ^ 35 xấp xỉ 32 * 2 ^ 30, 32 * 10 ^ 9. Điều đó đòi hỏi khoảng 11 chữ số thập phân, vì vậy với mười một số 9, chúng tôi chắc chắn sẽ tạo ra lỗi trên Squeak 32 bit. Trong 64 bit đó sẽ là hai mươi mốt 9.

Chúng ta cũng có thể cạn kiệt bộ nhớ với ít hơn 9 giây, toàn bộ không gian địa chỉ không nhất thiết phải có sẵn, nhưng nó rất chậm để kiểm tra, Squeak VM không được tối ưu hóa cho số học khổng lồ như vậy không giống như GMP.


Bạn có cần nhiều hơn bốn 9s không?
Joe Z.

@JoeZ. có hơn 4 nines.Smalltalk có LargeInteger số học và máy có bộ nhớ RAM lớn bây giờ ... thử nghiệm giới hạn chính xác là nhàm chán, trên 6 nines, trình biên dịch bắt đầu được sloooowwww
aka.nice

2

Đây là phương pháp ban đầu và ngắn gọn của tôi để đánh sập GolfScript:

{1.}do

Những gì nó làm là thiết lập một vòng lặp mãi mãi, tiếp tục đẩy 1 lên ngăn xếp cho đến khi hết bộ nhớ.

Trong C / C ++, tôi tin rằng đoạn mã gốc này sẽ làm sập trình biên dịch:

#define a bb
#define b aa
int main(){a}

Điều này sẽ khiến trình biên dịch bị kẹt gấp đôi số lượng của a và biến chúng thành b và ngược lại, do đó trình biên dịch sẽ sớm hết bộ nhớ và sụp đổ.

Một cái khác là cho lô trên Windows, nếu đóng băng hoàn toàn máy tính chứ không chỉ là tập lệnh bó. Bạn nên gõ như sau:

:a
start %0
goto a

Điều này đi vào một vòng lặp vô tận của việc tạo ra các bản sao của chính nó, tạo ra các bản sao của chính họ và vân vân. Điều này rất có thể cuối cùng sẽ làm hỏng máy tính của bạn nếu bạn chạy một chút mã này.

Một cái cuối cùng là một quả bom VBS. Nó là một quả bom khác, giống như quả bom cuối cùng, nhưng thay vào đó, nó mở ra vô số hộp thoại.

set oshell = wscript.createobject("wscript.shell")
do
oshell.run "wscript " & wscript.scriptname
msgbox "blah"
loop

Điều này liên tục tạo ra một bản sao của chính nó và mở ra một hộp thông báo trong một vòng lặp vô hạn, mà các bản sao cũng làm như vậy. Không nên chạy hai chương trình cuối cùng này vì chúng có thể đóng băng máy tính của bạn và khiến bạn phải khởi động cứng máy tính.

Lưu ý rằng tôi đã tự mình nghĩ ra tất cả các chương trình này.


1
C macro không tái diễn; bạn không thể phá vỡ bộ tiền xử lý C hoặc C ++ theo cách đó.
Joshua

2

Lisp thông thường, 8 byte

Ngắn hơn câu trả lời Lisp thông thường khác :-)

#.(loop)

Lặp lại trong khi đọc mẫu của bạn.

Tiêu chuẩn Common Lisp không đề cập đến một cách di động để làm cho nó bị sập, vì vậy tôi đoán chúng ta cần phải có một cách xác định theo cách thực hiện. Vẫn 8 byte:

#.(quit) ; ccl

... hoặc là,

#.(exit) ; sbcl

Khi bạn gọi (compile-file "crash.lisp"), môi trường "sụp đổ" một cách bí ẩn.

Đùa nhau, tôi vẫn đang cố gắng tìm cách khắc phục môi trường (và không lâu nữa), nhưng điều đó thực sự khó khăn. Tất cả những gì tôi nhận được là một sự tương tác tốt đẹp với trình gỡ lỗi.


2

x86 asm

"nasm -v" trả về "NASM phiên bản 2.11.08 được biên dịch vào ngày 21 tháng 2 năm 2015" (Tôi đang chạy nó dưới win7)

Trình biên dịch đã chạy trong 1:12:27 cho đến nay trên i7, hoàn toàn bão hòa một trong các lõi. Tệp đầu ra đang ở mức 0 byte, mức tiêu thụ bộ nhớ ổn định ở mức 1.004K - có vẻ an toàn khi nói rằng tôi đã đánh bại mọi thứ, thay vì chỉ thực hiện một nhiệm vụ thực sự rất dài. :)

Chìa khóa để lừa là giá trị lặp lại trong macro - 0xFFFFFFFF. Mặc dù vậy, tôi không đủ quen thuộc với những người bên trong của Nasm để biết tại sao chính xác nó lại nghẹt thở vì điều này. Tôi dự kiến ​​sẽ có được sản lượng ~ 16GB một giờ trước.

%MACRO INVOKE 1-*
;  %REP    %0 - 1
  %REP     0xffffffff
    %ROTATE   -1
    PUSH    DWORD %1
  %ENDREP
  %ROTATE -1
  CALL    %1
%ENDMACRO

[section .text]
bits 32
org 0x10000

EntryPoint:
    INVOKE dword 666
    ret

EDIT: Chỉ cần kiểm tra trình quản lý tác vụ, Nasm đã chạy trong 7:40:41 và bộ nhớ hiện đã lên tới 1.016K


2

Trình biên dịch Gnu, tạo các tệp đầu ra lớn

Macro này cố gắng lấp đầy tệp đầu ra với rác (thường là byte rỗng) cho đến khi đạt được ranh giới 4 GB, thêm một int để vượt qua ranh giới đó và gọi chính nó để tiếp tục lấp đầy đầu ra với 4 GB rác. Điều này sẽ lấp đầy ổ cứng của bạn cho đến khi nó đầy, lúc đó trình biên dịch sẽ có khả năng bị sập.

.macro f n #Define a macro named f, taking argument n.
.p2align 32 #Fill file with 0x00's until current address is divisible by 2^32
.long 0 #Add a long after the current address, throwing it off alignment.
.if \n #If n > 0, recursively tail-call itself, decrementing n.
f "(\n-1)"
.endif
.endm #End macro definition.
f 32 #Expand macro f, with n = 32 (output size 4GB*32 = 128GB)

Lưu ý rằng đệ quy vô hạn không thể được sử dụng, vì trình biên dịch sẽ bắt trường hợp đặc biệt đó và ngừng mở rộng macro.

Việc biên dịch có thể được thực hiện với as -o crash.out crash.shầu hết các bản phân phối Linux.


Bạn có thể bình luận nguồn? Tôi thực sự không hiểu những gì nó đang làm.
mèo

1
Bạn nên đăng bài này như một câu trả lời để Xây dựng bom biên dịch ! : D
con mèo

1

Lisp thông thường, 29 byte

Thực hiện: Clozure CL

CẢNH BÁO: Cẩn thận khi chạy mã này, nó có thể giết chết các quy trình mà bạn không muốn nó!

#.(run-program"pkill"'("cl"))

Điều này chạy lệnh shell pkill clvào thời gian biên dịch, sẽ giết tiến trình Lisp khi biên dịch. Về mặt kỹ thuật không phải là một sự cố, nhưng nó có tác dụng tương tự.

Ví dụ sử dụng:

$ cat /tmp/t.lisp
#.(run-program "pkill" '("cl"))
$ ccl -n
Welcome to Clozure Common Lisp Version 1.11-dev-r16513-trunk  (LinuxX8664)!

? (compile-file "/tmp/t.lisp")
#P"/tmp/t.lx64fsl"
NIL
NIL
?
zsh: terminated  ccl -n
$ 

1

Felix

Điều này không còn hoạt động nữa, nhưng tại một thời điểm, mã này:

include "std/control/pchannels";

fun is_square(v: int) => let s = int$ sqrt$ v.float + 0.5f in s*s == v;
fun is_median(v: int) => v % 4 == 0 and (v/4).is_square;

struct Message { value: int; };

proc process(c: int, chan: pchannel[Message]) {
    var i = 0;
    for var b in (c+1)/2 upto c do
        for var a in c - b + 1 upto b do
            if is_median(2*(b*b+c*c)-a*a) or
               is_median(2*(a*a+c*c)-b*b) or
               is_median(2*(a*a+b*b)-c*c) do ++i; done;
        done
    done
    write(chan, Message i);
};

proc main() {
    n := int$ System::argv 1;
    var count = n;
    chan := #mk_pchannel[Message];
    var ntri = 0;

    for var c in 1 upto n perform spawn_pthread { process(c, chan); };

    while count > 0 do
        let v = chan.read in ntri += v.value;
        --count;
    done
    ntri.println;
}

main;

Điều này sẽ cho một lỗi lớn:

inner_bind_expression raised Not_found [BUG] e=(&((main_mf_60270<60270> ())), (value v))

HỆ THỐNG FAILURE bind_expression 'nâng lên Not_found [BUG] Trình biên dịch Felix "/ media / ryan / Stuff / felix / build / release / host / bin / flxg" "-q" "--optimise" "--inline = 100" "- output_dir = / home / ryan / Stuff / .felix / text "" --cache_dir = / home / ryan / Stuff / .felix / cache "" -I / media / ryan / Stuff / felix / build / release / share / lib "" -I / media / ryan / Stuff / felix / build / release / host / lib "" --syntax=@/media/ryan/ ware / felix / build / release / share / lib / grammar / grammar.files " "--automaton = / home / ryan / Stuff / .felix / cache / media / ryan / Stuff / felix / build / release / share / lib / grammar / grammar.files / cú pháp.automaton" "--import = plat / flx.flxh "" std "" /home/ryan/golf/itri/sl.flx "không thành công Lỗi 1 trong flx: [strerror_r] Không thể tìm thấy văn bản cho lỗi số 1

Vấn đề là ở đây:

let v = chan.read in ntri += v.value;

letmong đợi một biểu thức để theo nó, nhưng tôi đặt một tuyên bố thay thế. Vì vậy, trình biên dịch hoảng loạn một chút.

Thông tin thêm tại https://groups.google.com/forum/m/#!topic/felix-lingu/J3Hs4j6E0gM .


1

JavaScript

while (true === true){
console.log(0);
}

Điều này gửi nó vào một vòng lặp vô hạn. Tôi đã sử dụng trình biên dịch Codecademy JS và nó bị sập trình duyệt của tôi.


1
Đó có phải là trình biên dịch hoặc thời gian chạy bị lỗi không? Trình duyệt web bao gồm cả hai, nhưng tôi cho rằng chúng vẫn là các thành phần riêng biệt.
Thực phẩm điện tử

Trình biên dịch bị lỗi, đóng băng trình duyệt của tôi. @ Hand-E-Food
juniorRubyist

1
Đây không phải là sự cố trình biên dịch; nó đang treo trang web của bạn. Ngoài ra, bạn chỉ có thể viết while(1){}; đây cũng là một vòng lặp vô hạn.
SirPython

Một ví dụ thậm chí ngắn hơn là while(1);.
Aplet123

1

Javascript

function crash(){
  window.location.hash=Math.random(),onhashchange=function(){crash()}
}

Điều này làm sập các trình duyệt web một cách hiệu quả nghiêm trọng. SỬ DỤNG CÓ NGUY CƠ CỦA RIÊNG BẠN!!!


3
Các phương tiện chính xác của vụ tai nạn là gì? Cụ thể, câu hỏi này là về các trình biên dịch bị lỗi và điều này dường như chỉ làm cho trình duyệt bị chết chứ không phải trình biên dịch nội bộ JS.
Petr Pudlák

FF từ chối gặp sự cố; chạy cái này trong Chrome đã treo hệ thống của tôi.
mèo

1

Kali

Tệp1.has:

use "File2.has";

Tệp2.has:

use "File1.has";

Điều này làm cho Kali tải và bắt đầu biên dịch File2.has, điều này bảo nó tải File1.has, khiến nó tải File2.has, v.v.


0

LOLCODE 1.2, Trình biên dịch / Trình biên dịch chung LOLCODE (lci)

Tôi biết đây không phải là nhưng dù sao nó cũng rất ngắn.

OBTW

Điều này gây ra Tín hiệu 11:

Segmentation fault (core dumped)


Tại sao? HAI1.2biểu thị sự bắt đầu của chương trình và OBTWbắt đầu một bình luận đa dòng. Nhưng trình biên dịch hy vọng một KTHXBYEđể đóng HAI, và một TLDRđể đóng những nhận xét có nhiều dòng.

Lưu ý rằng điều này vẫn sẽ hoạt động để gây ra segfault với bất cứ điều gì khác ngoài TLDRsauOBTW .

(Theo tiêu chuẩn của wikipedia , LOLCODE chỉ là một Weirdlang, không thực sự bí truyền.)
Bạn có thể lấy trình thông dịch từ git / justinmeza / lci .


"Sử dụng một ngôn ngữ tiêu chuẩn được sử dụng trong thế giới thực." Bạn có nghĩa là nói với tôi rằng bạn sẽ sử dụng lolcode để viết một chương trình hợp pháp?
Patrick Roberts

@PatrickRoberts Vâng, tôi sẽ. / s
vỗ tay
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.