我试图使一个Python程序接口与不同的崩溃进程(这是我的手)。不幸的是，我正在使用的程序甚至不会可靠地崩溃!所以我想做一个快速的c++程序，它会故意崩溃，但我不知道最好和最短的方法来做到这一点，有人知道在我的
int main() {
crashyCodeGoesHere();
}
使我的c++程序可靠地崩溃
当前回答
Try:
raise(SIGSEGV); // simulates a standard crash when access invalid memory
// ie anything that can go wrong with pointers.
中发现:
#include <signal.h>
其他回答
答案是平台特定的，取决于你的目标。但这里是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
}
死循环递归方法调用导致堆栈溢出怎么办?
#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上的原始示例
int i = 1 / 0;
您的编译器可能会警告您这一点，但在GCC 4.4.3下它编译得很好 这可能会导致SIGFPE(浮点异常)，这在实际应用程序中可能不像SIGSEGV(内存分段违反)那样可能导致其他答案，但它仍然是崩溃。在我看来，这样可读性更强。
另一种方法，如果我们要欺骗和使用signal.h，是:
#include <signal.h>
int main() {
raise(SIGKILL);
}
这保证杀死子进程，与SIGSEGV形成对比。
char*freeThis;
free(freeThis);
释放未初始化的指针是未定义的行为。在许多平台/编译器上，freeThis将有一个随机值(无论之前在内存位置上是什么)。释放它将要求系统释放该地址的内存，这通常会导致分割错误并使程序崩溃。
这是Breakpad中谷歌提供的代码片段。
volatile int* a = reinterpret_cast<volatile int*>(NULL);
*a = 1;
