Cách dễ nhất để làm cho một chương trình C ++ sụp đổ là gì?

Tôi đang cố gắng tạo một chương trình Python có giao diện với một quy trình khác nhau (điều đó nằm ngoài tầm tay của tôi). Thật không may, chương trình tôi đang can thiệp thậm chí không sụp đổ đáng tin cậy! Vì vậy, tôi muốn tạo một chương trình C ++ nhanh chóng gặp sự cố nhưng tôi thực sự không biết cách tốt nhất và ngắn nhất để làm điều đó, có ai biết phải đặt gì giữa tôi không:

int main() {
    crashyCodeGoesHere();
}

để làm cho chương trình C ++ của tôi bị sập một cách đáng tin cậy

Các abort()chức năng có lẽ là đặt cược tốt nhất của bạn. Đây là một phần của thư viện chuẩn C và được định nghĩa là "gây ra sự chấm dứt chương trình bất thường" (ví dụ: lỗi nghiêm trọng hoặc sự cố).

Thử:

raise(SIGSEGV);  // simulates a standard crash when access invalid memory
                 // ie anything that can go wrong with pointers.

Tìm thấy trong:

#include <signal.h>

Chia cho số 0 sẽ làm hỏng ứng dụng:

int main()
{
    return 1 / 0;
}

*((unsigned int*)0) = 0xDEAD;

Vâng, chúng ta có đang tràn stack hay không?

for (long long int i = 0; ++i; (&i)[i] = i);

(Không được đảm bảo để sụp đổ theo bất kỳ tiêu chuẩn nào, nhưng không có bất kỳ câu trả lời được đề xuất nào kể cả câu trả lời được chấp nhận vì SIGABRTdù sao cũng có thể bị bắt. Trong thực tế, điều này sẽ sụp đổ ở mọi nơi.)

 throw 42;

Chỉ cần câu trả lời ... :)

assert(false); cũng khá tốt

Theo ISO / IEC 9899: 1999, nó được bảo đảm sự cố khi không xác định được NDEBUG:

Nếu NDEBUG được xác định [...] thì macro xác nhận được định nghĩa đơn giản là

#define assert(ignore) ((void)0)

Macro xác nhận được xác định lại theo trạng thái hiện tại của NDEBUG mỗi lần được đưa vào.

[...]

Macro khẳng định đưa các xét nghiệm chẩn đoán vào các chương trình; [...] nếu biểu thức (sẽ có kiểu vô hướng) là sai [...]. Sau đó, nó gọi hàm hủy bỏ.

Vì sự cố là một triệu chứng của việc gọi hành vi không xác định và vì việc gọi hành vi không xác định có thể dẫn đến bất cứ điều gì, kể cả sự cố, tôi không nghĩ rằng bạn muốn thực sự làm hỏng chương trình của mình, nhưng chỉ cần thả nó vào trình gỡ lỗi. Cách di động nhất để làm như vậy có lẽ là abort().

Trong khi raise(SIGABRT)có tác dụng tương tự, nó chắc chắn là nhiều hơn để viết. Tuy nhiên, cả hai cách đều có thể bị chặn bằng cách cài đặt bộ xử lý tín hiệu cho SIGABRT. Vì vậy, tùy thuộc vào tình huống của bạn, bạn có thể muốn / cần tăng tín hiệu khác. SIGFPE, SIGILL, SIGINT, SIGTERMHoặc SIGSEGVcó thể là cách để đi, nhưng tất cả đều có thể bị chặn.

Khi bạn có thể không thể truy cập được, các lựa chọn của bạn có thể còn rộng hơn, như sử dụng SIGBUStrên linux.

Đèn flash duy nhất tôi có là hàm abort () :

Nó hủy bỏ quá trình với một chấm dứt chương trình bất thường. Nó tạo ra tín hiệu SIGABRT , theo mặc định khiến chương trình chấm dứt trả lại mã lỗi kết thúc không thành công cho môi trường máy chủ. Chương trình bị chấm dứt mà không thực hiện các hàm hủy cho các đối tượng có thời gian lưu trữ tự động hoặc tĩnh và không gọi bất kỳ atexit nào (được gọi bởi exit () trước khi hàm kết thúc chương trình). Nó không bao giờ trở lại với người gọi của nó.

Câu trả lời là nền tảng cụ thể và phụ thuộc vào mục tiêu của bạn. Nhưng đây là chức năng sự cố Mozilla Javascript, mà tôi nghĩ minh họa rất nhiều thách thức để thực hiện công việc này:

static JS_NEVER_INLINE void
CrashInJS()
{
    /*
     * We write 123 here so that the machine code for this function is
     * unique. Otherwise the linker, trying to be smart, might use the
     * same code for CrashInJS and for some other function. That
     * messes up the signature in minidumps.
     */

#if defined(WIN32)
    /*
     * We used to call DebugBreak() on Windows, but amazingly, it causes
     * the MSVS 2010 debugger not to be able to recover a call stack.
     */
    *((int *) NULL) = 123;
    exit(3);
#elif defined(__APPLE__)
    /*
     * On Mac OS X, Breakpad ignores signals. Only real Mach exceptions are
     * trapped.
     */
    *((int *) NULL) = 123;  /* To continue from here in GDB: "return" then "continue". */
    raise(SIGABRT);  /* In case above statement gets nixed by the optimizer. */
#else
    raise(SIGABRT);  /* To continue from here in GDB: "signal 0". */
#endif
}

Tôi thấy có nhiều câu trả lời được đăng ở đây sẽ rơi vào những trường hợp may mắn để hoàn thành công việc, nhưng không có câu trả lời nào trong số đó là 100% xác định để sụp đổ. Một số sẽ sụp đổ trên một phần cứng và hệ điều hành, những cái khác thì không. Tuy nhiên, có một cách tiêu chuẩn theo tiêu chuẩn C ++ chính thức để làm cho nó sụp đổ.

Trích dẫn từ tiêu chuẩn ISO / IEC 14882 §15.1-7 của C ++ :

Nếu cơ chế xử lý ngoại lệ, sau khi hoàn thành việc khởi tạo đối tượng ngoại lệ nhưng trước khi kích hoạt trình xử lý ngoại lệ, hãy gọi một hàm thoát qua một ngoại lệ, std :: terminating được gọi là (15.5.1).

struct C {
    C() { }
    C(const C&) {
        if (std::uncaught_exceptions()) {
            throw 0; // throw during copy to handler’s exception-declaration object (15.3)
        }
    }
};
int main() {
    try {
    throw C(); // calls std::terminate() if construction of the handler’s
    // exception-declaration object is not elided (12.8)
    } catch(C) { }
}

Tôi đã viết một mã nhỏ để chứng minh điều này và có thể được tìm thấy và thử trên Ideone tại đây .

class MyClass{
    public:
    ~MyClass() throw(int) { throw 0;}
};

int main() {
  try {
    MyClass myobj; // its destructor will cause an exception

    // This is another exception along with exception due to destructor of myobj and will cause app to terminate
     throw 1;      // It could be some function call which can result in exception.
  }
  catch(...)
  {
    std::cout<<"Exception catched"<<endl;
  }
  return 0;
}

ISO / IEC 14882 §15.1 / 9 đề cập đến việc ném mà không thử khối dẫn đến lệnh hủy bỏ ngầm định:

Nếu hiện tại không có ngoại lệ nào được xử lý, thực thi biểu thức ném mà không có lệnh gọi toán hạng std :: terminating ()

Những thứ khác bao gồm: ném từ hàm hủy: ISO / IEC 14882 §15.2 / 3

*( ( char* ) NULL ) = 0;

Điều này sẽ tạo ra một lỗi phân khúc.

Cái này bị thiếu:

int main = 42;

Điều gì về tràn ngăn xếp bởi một cuộc gọi phương thức đệ quy vòng lặp chết?

#include <windows.h>
#include <stdio.h>

void main()
{
    StackOverflow(0);
}

void StackOverflow(int depth)
{
    char blockdata[10000];
    printf("Overflow: %d\n", depth);
    StackOverflow(depth+1);
}

Xem ví dụ ban đầu trên Microsoft KB

Sự cố này xảy ra trên hệ thống Linux của tôi, vì chuỗi ký tự được lưu trữ trong bộ nhớ chỉ đọc:

0[""]--;

Nhân tiện, g ++ từ chối biên dịch cái này. Trình biên dịch ngày càng thông minh hơn và thông minh hơn :)

int i = 1 / 0;

Trình biên dịch của bạn có thể sẽ cảnh báo bạn về điều này, nhưng nó chỉ biên dịch tốt trong GCC 4.4.3 Điều này có thể sẽ gây ra SIGFPE (ngoại lệ dấu phẩy động), có lẽ không có trong ứng dụng thực như SIGSEGV (vi phạm phân đoạn bộ nhớ) như các câu trả lời khác gây ra, nhưng nó vẫn là một sự cố. Theo tôi, điều này dễ đọc hơn nhiều.

Một cách khác, nếu chúng ta sẽ gian lận và sử dụng signal.h, là:

#include <signal.h>
int main() {
    raise(SIGKILL);
}

Điều này được đảm bảo để tiêu diệt quá trình con, tương phản với SIGSEGV.

Đây là phiên bản hủy bỏ được bảo đảm hơn được trình bày trong các câu trả lời ở trên. Nó xử lý tình huống khi sigabrt bị chặn. Bạn có thể sử dụng bất kỳ tín hiệu nào thay vì hủy bỏ có hành động mặc định làm sập chương trình.

#include<stdio.h>
#include<signal.h>
#include<unistd.h> 
#include<stdlib.h>
int main()
{
    sigset_t act;
    sigemptyset(&act);
    sigfillset(&act);
    sigprocmask(SIG_UNBLOCK,&act,NULL);
    abort();
}

int* p=0;
*p=0;

Điều này sẽ sụp đổ quá. Trên Windows, nó gặp sự cố với AccessViolation và nó sẽ làm tương tự trên tất cả các hệ điều hành tôi đoán.

Đây là đoạn trích được cung cấp bởi Google trong Breakpad.

  volatile int* a = reinterpret_cast<volatile int*>(NULL);
  *a = 1;

int main(int argc, char *argv[])
{
    char *buf=NULL;buf[0]=0;
    return 0;
}

Mặc dù câu hỏi này đã có câu trả lời được chấp nhận ...

void main(){
    throw 1;
}

Hoặc là... void main(){throw 1;}

Ghi vào bộ nhớ chỉ đọc sẽ gây ra lỗi phân đoạn trừ khi hệ thống của bạn không hỗ trợ các khối bộ nhớ chỉ đọc.

int main() {
    (int&)main = 0;
}

Tôi đã thử nghiệm nó với MingGW 5.3.0 trên Windows 7 và GCC trên Linux Mint. Tôi cho rằng các trình biên dịch và hệ thống khác sẽ cho hiệu ứng tương tự.

Hoặc một cách khác kể từ khi chúng tôi ở trong đoàn xe.

Một mảnh đáng yêu của đệ quy vô hạn. Đảm bảo để thổi stack của bạn.

int main(int argv, char* argc)
{
   return main(argv, argc)
}

In ra:

Lỗi phân đoạn (đổ lõi)

Một điều chưa được đề cập:

((void(*)())0)();

Điều này sẽ coi con trỏ null là một con trỏ hàm và sau đó gọi nó. Giống như hầu hết các phương thức, điều này không được đảm bảo để làm hỏng chương trình, nhưng khả năng HĐH cho phép điều này không được kiểm soát và chương trình sẽ quay trở lại là không đáng kể.

void main()
{

  int *aNumber = (int*) malloc(sizeof(int));
  int j = 10;
  for(int i = 2; i <= j; ++i)
  {
      aNumber = (int*) realloc(aNumber, sizeof(int) * i);
      j += 10;
  }

}

Hy vọng điều này sụp đổ. Chúc mừng.

int main()
{
    int *p=3;
    int s;
    while(1) {
        s=*p;
        p++;
    }
}

Một cách sành điệu để làm điều này là một cuộc gọi chức năng ảo thuần túy:

class Base;

void func(Base*);

class Base
{
public:
   virtual void f() = 0;
   Base() 
   {
       func(this);
   }
};

class Derived : Base
{
   virtual void f()
   {
   }
};

void func(Base* p)
{
   p->f();
}


int main()
{
    Derived  d;
}

Được biên dịch với gcc, bản in này:

phương pháp ảo thuần túy được gọi là

chấm dứt được gọi mà không có ngoại lệ hoạt động

Đã hủy bỏ (đổ lõi)

Bạn có thể sử dụng lắp ráp trong c ++ code BUT của mình INT 3 chỉ dành cho các hệ thống x86, các hệ thống khác có thể có các hướng dẫn bẫy / điểm dừng khác.

int main()
{
    __asm int 3;

    return 0;
}

INT 3 gây ra một ngắt và gọi một vectơ ngắt được thiết lập bởi HĐH.

Sử dụng __builtin_trap () trong GCC hoặc clang hoặc __debugbreak () trong MSVC. Không xử lý các điểm dừng / bẫy này sẽ dẫn đến ngoại lệ / sự cố điểm dừng chưa được xử lý. Các đề xuất khác sử dụng abort () hoặc exit (): những đề xuất này có thể được xử lý bởi các luồng khác, khiến cho việc nhìn thấy ngăn xếp của luồng phát tán sự cố trở nên khó khăn hơn.

char*freeThis;
free(freeThis);

Giải phóng một con trỏ chưa được khởi tạo là hành vi không xác định. Trên nhiều nền tảng / trình biên dịch, freeThissẽ có một giá trị ngẫu nhiên (bất cứ thứ gì đã ở vị trí bộ nhớ đó trước đó). Giải phóng nó sẽ yêu cầu hệ thống giải phóng bộ nhớ tại địa chỉ đó, điều này thường sẽ gây ra lỗi phân đoạn và làm cho chương trình bị sập.