这是上面回答中给出的一个更有保证的abort版本。它负责处理sigabrt被阻塞时的情况。实际上，您可以使用任何信号来代替具有使程序崩溃的默认操作的abort。

#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一起崩溃，我猜它应该在所有操作系统上都是一样的。

答案是平台特定的，取决于你的目标。但这里是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
}

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将有一个随机值(无论之前在内存位置上是什么)。释放它将要求系统释放该地址的内存，这通常会导致分割错误并使程序崩溃。

除以0会导致应用程序崩溃:

int main()
{
    return 1 / 0;
}