C ++プログラムをクラッシュさせる最も簡単な方法は何ですか？

別のクラッシュしたプロセスとインターフェースするPythonプログラムを作成しようとしています（手に負えない）。残念ながら、私が接続しているプログラムは確実にクラッシュすることすらありません！だから私は意図的にクラッシュする簡単なC ++プログラムを作りたいのですが、実際にはそれを行うための最善かつ最短の方法がわかりません。

int main() {
    crashyCodeGoesHere();
}

C ++プログラムを確実にクラッシュさせる

abort()この関数は、おそらくあなたの最善の策です。これはC標準ライブラリの一部であり、「プログラムの異常終了（致命的なエラーやクラッシュなど）」と定義されています。

試してください：

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

にあります：

#include <signal.h>

ゼロで除算すると、アプリケーションがクラッシュします。

int main()
{
    return 1 / 0;
}

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

さて、私たちはスタックオーバーフローをしていますか？

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

（標準でクラッシュすることは保証されていませんが、SIGABRTとにかくキャッチされている可能性があるため、承認されたものを含め、提案された回答はどれもありません。実際、これはどこでもクラッシュします。）

 throw 42;

ちょうど答え... :)

assert(false); かなり良いです。

ISO / IEC 9899：1999によると、NDEBUGが定義されていない場合はクラッシュすることが保証されています。

NDEBUGが定義されている場合[...] assertマクロは次のように定義されます

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

アサートマクロは、NDEBUGが含まれるたびに、NDEBUGの現在の状態に従って再定義されます。

[...]

assertマクロは、診断テストをプログラムに入れます。[...]式（スカラー型でなければならない）がfalseの場合[...]。次に、abort関数を呼び出します。

クラッシュは未定義の動作を呼び出すことの症状であり、未定義の動作を呼び出すとクラッシュを含む何かにつながる可能性があるため、プログラムを実際にクラッシュさせたくはありませんが、デバッガーにドロップするだけです。そうするための最もポータブルな方法は、おそらくabort()です。

一方でraise(SIGABRT)同じ効果があり、それは確かに多くの書き込みにあります。ただし、両方の方法は、のシグナルハンドラをインストールすることで傍受できますSIGABRT。したがって、状況によっては、別のシグナルを発信する必要がある場合があります。SIGFPE、SIGILL、SIGINT、SIGTERMまたはSIGSEGV移動するための方法かもしれませんが、それらはすべて傍受することができます。

移植できない場合はSIGBUS、Linuxでの使用のように、選択肢がさらに広がる可能性があります。

私が持っていた唯一のフラッシュはabort（）関数です：

これは、プログラムの異常終了によりプロセスを中止します。SIGABRTシグナルを生成します。これにより、デフォルトでプログラムは終了し、ホスト環境に失敗した終了エラーコードを返します。自動または静的ストレージ期間のオブジェクトのデストラクタを実行せずにプログラムは終了します、およびatexit（プログラムが終了する前にexit（）によって呼び出される）関数を呼び出さない。呼び出し元に戻ることはありません。

答えはプラットフォーム固有であり、目標によって異なります。しかし、これがMozillaのJavascriptクラッシュ機能です。これは、この機能を実現するための多くの課題を示していると思います。

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
}

ここに投稿された多くの回答が、仕事を成し遂げるためのラッキーケースに該当するようですが、どれもクラッシュすることが100％確定的ではありません。一部は1つのハードウェアとOSでクラッシュしますが、他はクラッシュしません。ただし、それをクラッシュさせるための公式のC ++標準ごとの標準的な方法があります。

C ++標準ISO / IEC 14882§15.1-7からの引用：

例外処理メカニズムが、例外オブジェクトの初期化を完了した後、例外のハンドラーをアクティブ化する前に、例外を介して終了する関数を呼び出すと、std :: terminateが呼び出されます（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) { }
}

私はこれを実証するために小さなコードを書いており、ここでIdeoneで見つけて試してみることができます。

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は、tryブロックなしでスローすると、アボートの暗黙的な呼び出しが発生することに言及しています。

現在処理されている例外がない場合、オペランドを指定せずにスロー式を実行すると、std :: terminate（）が呼び出されます。

その他には、デストラクタからスロー：ISO / IEC 14882§15.2/ 3

*( ( char* ) NULL ) = 0;

これにより、セグメンテーション違反が発生します。

これはありません：

int main = 42;

デッドループ再帰メソッド呼び出しによるスタックオーバーフローはどうですか？

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

Microsoft KBの元の例を参照してください

文字列リテラルが読み取り専用メモリに格納されているため、これは私のLinuxシステムでクラッシュします。

0[""]--;

ちなみに、g ++はこれをコンパイルすることを拒否します。コンパイラはますます賢くなっています:)

int i = 1 / 0;

コンパイラはおそらくこれについて警告しますが、GCC 4.4.3では正常にコンパイルされます。これはおそらく SIGFPE（浮動小数点例外）を引き起こします。これは、実際のアプリケーションではSIGSEGV（メモリセグメンテーション違反）ほど可能性が低いです。他の答えが原因ですが、それでもクラッシュです。私の意見では、これはもっと読みやすいです。

別の方法として、チートしてを使用する場合は、次のようになりますsignal.h。

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

これは、SIGSEGVとは対照的に、サブプロセスを強制終了することが保証されています。

これは、上記の回答で示された、より保証されたアボートバージョンです。これは、sigabrtがブロックされた場合の状況に対応します。プログラムをクラッシュさせるデフォルトのアクションを持つアボートの代わりに、任意の信号を使用できます。

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

これもクラッシュするはずです。WindowsではAccessViolationでクラッシュし、私が推測するすべてのOSで同じように動作するはずです。

これは、Googleが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;
}

この質問にはすでに受け入れられた答えがありますが...

void main(){
    throw 1;
}

または... void main(){throw 1;}

システムが読み取り専用メモリブロックをサポートしていない場合を除き、読み取り専用メモリに書き込むと、セグメンテーション違反が発生します。

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

Windows 7ではMingGW 5.3.0、Linux MintではGCCでテストしました。他のコンパイラやシステムでも同様の効果が得られると思います。

または、バンドワゴンを使用しているため、別の方法です。

無限再帰の素敵な作品。スタックを爆破することが保証されています。

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

プリントアウト：

セグメンテーション違反（コアダンプ）

まだ言及されていないもの：

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

これは、nullポインターを関数ポインターとして扱い、それを呼び出します。ほとんどのメソッドと同様に、これはプログラムのクラッシュを保証するものではありませんが、OSがこれをチェックしない状態にして、プログラムが戻る可能性はごくわずかです。

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

}

これがクラッシュすることを願っています。乾杯。

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

これを行うスタイリッシュな方法は、純粋な仮想関数呼び出しです。

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

gccでコンパイルすると、次のように表示されます。

呼び出された純粋な仮想メソッド

アクティブな例外なしで呼び出された終了

中止（コアダンプ）

あなたは、C ++でアセンブリを使用することができますcode しかし INT 3、他のシステムは、他のトラップ/ブレークポイント命令を有することができる唯一のx86システム用です。

int main()
{
    __asm int 3;

    return 0;
}

INT 3 割り込みを発生させ、OSが設定した割り込みベクトルを呼び出します。

GCCまたはclangでは__builtin_trap（）を、MSVCでは__debugbreak（）を使用します。これらのブレークポイント/トラップを処理しないと、未処理のブレークポイント例外/クラッシュが発生します。abort（）またはexit（）を使用する他の提案：これらは他のスレッドによって処理される可能性があるため、クラッシュを伝播したスレッドのスタックを確認することがより困難になります。

char*freeThis;
free(freeThis);

初期化されていないポインタの解放は、未定義の動作です。多くのプラットフォーム/コンパイラでfreeThisは、ランダムな値になります（以前にそのメモリ位置にあったものは何でも）。それを解放すると、そのアドレスでメモリを解放するようシステムに要求します。これは通常、セグメンテーション違反を引き起こし、プログラムをクラッシュさせます。