Was ist der einfachste Weg, um ein C ++ - Programm zum Absturz zu bringen?

Ich versuche, ein Python-Programm zu erstellen, das mit einem anderen Absturzprozess verbunden ist (das liegt nicht in meiner Hand). Leider stürzt das Programm, mit dem ich verbunden bin, nicht einmal zuverlässig ab! Ich möchte also ein schnelles C ++ - Programm erstellen, das absichtlich abstürzt, aber ich weiß nicht, wie ich das am besten und kürzesten machen kann. Weiß jemand, was ich zwischen meine:

int main() {
    crashyCodeGoesHere();
}

damit mein C ++ - Programm zuverlässig abstürzt

Die abort()Funktion ist wahrscheinlich die beste Wahl. Es ist Teil der C-Standardbibliothek und wird als "Verursachen einer abnormalen Programmbeendigung" definiert (z. B. ein schwerwiegender Fehler oder Absturz).

Versuchen:

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

Gefunden in:

#include <signal.h>

Durch Teilen durch Null stürzt die Anwendung ab:

int main()
{
    return 1 / 0;
}

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

Nun sind wir auf Stack - Überlauf , oder nicht?

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

(Es ist nicht garantiert, dass es nach irgendwelchen Maßstäben abstürzt, aber es gibt auch keine der vorgeschlagenen Antworten, einschließlich der akzeptierten, da SIGABRTes ohnehin hätte abgefangen werden können. In der Praxis wird dies überall abstürzen.)

 throw 42;

Nur die Antwort ... :)

assert(false); ist auch ziemlich gut.

Gemäß ISO / IEC 9899: 1999 ist ein Absturz garantiert, wenn NDEBUG nicht definiert ist:

Wenn NDEBUG [...] definiert ist, wird das Assert-Makro einfach als definiert

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

Das Assert-Makro wird jedes Mal, wenn es enthalten ist, entsprechend dem aktuellen Status von NDEBUG neu definiert.

[...]

Das Assert-Makro fügt Diagnosetests in Programme ein. [...] wenn der Ausdruck (der einen Skalartyp haben soll) falsch ist [...]. Es ruft dann die Abbruchfunktion auf.

Da ein Absturz ein Symptom für das Aufrufen von undefiniertem Verhalten ist und das Aufrufen von undefiniertem Verhalten zu allem führen kann, einschließlich eines Absturzes, denke ich nicht, dass Sie Ihr Programm wirklich zum Absturz bringen möchten, sondern es einfach in einen Debugger fallen lassen möchten. Der tragbarste Weg, dies zu tun, ist wahrscheinlich abort().

Während raise(SIGABRT)es den gleichen Effekt hat, ist es sicherlich mehr zu schreiben. Beide Möglichkeiten können jedoch durch Installieren eines Signalhandlers für abgefangen werden SIGABRT. Abhängig von Ihrer Situation möchten / müssen Sie möglicherweise ein anderes Signal auslösen. SIGFPE, SIGILL, SIGINT, SIGTERMOder SIGSEGVkönnte der Weg zu gehen, aber sie alle abgefangen werden können.

Wenn Sie nicht portierbar sind, sind Ihre Auswahlmöglichkeiten möglicherweise noch umfangreicher, z. B. unter SIGBUSLinux.

Der einzige Blitz, den ich hatte, ist die Funktion abort () :

Es bricht den Prozess mit einer abnormalen Programmbeendigung ab. Es erzeugt das SIGABRT-Signal , das standardmäßig dazu führt, dass das Programm beendet wird und ein nicht erfolgreicher Beendigungsfehlercode an die Host-Umgebung zurückgegeben wird. Das Programm wird beendet, ohne Destruktoren für Objekte mit automatischer oder statischer Speicherdauer auszuführen und ohne Aufrufen einer Funktion atexit (die von exit () aufgerufen wird, bevor das Programm beendet wird). Es kehrt nie zu seinem Anrufer zurück.

Die Antwort ist plattformspezifisch und hängt von Ihren Zielen ab. Aber hier ist die Mozilla Javascript-Absturzfunktion, die meiner Meinung nach viele Herausforderungen für diese Funktion veranschaulicht:

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
}

Ich sehe, dass hier viele Antworten veröffentlicht werden, die in glückliche Fälle geraten, um die Arbeit zu erledigen, aber keine von ihnen ist zu 100% deterministisch für einen Absturz. Einige stürzen auf einer Hardware und einem Betriebssystem ab, andere nicht. Es gibt jedoch eine Standardmethode gemäß dem offiziellen C ++ - Standard, um einen Absturz zu verursachen.

Zitat aus C ++ Standard ISO / IEC 14882 §15.1-7 :

Wenn der Mechanismus zur Ausnahmebehandlung nach Abschluss der Initialisierung des Ausnahmeobjekts, jedoch vor der Aktivierung eines Handlers für die Ausnahme, eine Funktion aufruft, die über eine Ausnahme beendet wird, wird std :: terminate aufgerufen (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) { }
}

Ich habe einen kleinen Code geschrieben, um dies zu demonstrieren, und kann hier auf Ideone gefunden und ausprobiert werden .

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 erwähnt den Wurf ohne Try-Block, was zu einem impliziten Aufruf zum Abbruch führt:

Wenn derzeit keine Ausnahme behandelt wird, ruft das Ausführen eines Wurfausdrucks ohne Operanden std :: terminate () auf.

Andere schließen ein: vom Zerstörer werfen: ISO / IEC 14882 §15.2 / 3

*( ( char* ) NULL ) = 0;

Dies führt zu einem Segmentierungsfehler.

Dieser fehlt:

int main = 42;

Was ist mit einem Stapelüberlauf durch einen rekursiven Methodenaufruf in einer toten Schleife?

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

Siehe Originalbeispiel in Microsoft KB

Dies stürzt auf meinem Linux-System ab, da Zeichenfolgenliterale im Nur-Lese-Speicher gespeichert sind:

0[""]--;

G ++ weigert sich übrigens, dies zu kompilieren. Compiler werden immer schlauer :)

int i = 1 / 0;

Ihr Compiler wird Sie wahrscheinlich davor warnen, aber unter GCC 4.4.3 wird er problemlos kompiliert. Dies führt wahrscheinlich zu einem SIGFPE (Gleitkomma-Ausnahme), das in einer realen Anwendung möglicherweise nicht so wahrscheinlich ist wie SIGSEGV (Speichersegmentierungsverletzung) wie Die anderen Antworten verursachen, aber es ist immer noch ein Absturz. Meiner Meinung nach ist dies viel besser lesbar.

Ein anderer Weg, wenn wir betrügen und benutzen wollen signal.h, ist:

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

Dies ist im Gegensatz zu SIGSEGV garantiert, um den Unterprozess abzubrechen.

Dies ist eine garantiertere Version des Abbruchs, die in den obigen Antworten dargestellt ist. Sie kümmert sich um die Situation, in der Sigabrt blockiert ist. Sie können jedes Signal anstelle des Abbruchs verwenden, bei dem das Programm standardmäßig abstürzt.

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

Dies sollte auch abstürzen. Unter Windows stürzt es mit AccessViolation ab und sollte auf allen Betriebssystemen, denke ich, dasselbe tun.

Dies ist das von Google in Breakpad bereitgestellte Snippet.

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

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

Obwohl diese Frage bereits eine akzeptierte Antwort hat ...

void main(){
    throw 1;
}

Oder... void main(){throw 1;}

Das Schreiben in einen Nur-Lese-Speicher führt zu einem Segmentierungsfehler, es sei denn, Ihr System unterstützt keine Nur-Lese-Speicherblöcke.

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

Ich habe es mit MingGW 5.3.0 unter Windows 7 und GCC unter Linux Mint getestet. Ich nehme an, dass andere Compiler und Systeme einen ähnlichen Effekt erzielen.

Oder anders, seit wir auf dem Bandwagen sind.

Ein schönes Stück unendlicher Rekursion. Garantiert, um Ihren Stapel zu sprengen.

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

Druckt aus:

Segmentierungsfehler (Core Dumped)

Eine, die noch nicht erwähnt wurde:

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

Dadurch wird der Nullzeiger als Funktionszeiger behandelt und dann aufgerufen. Wie bei den meisten Methoden kann nicht garantiert werden, dass das Programm abstürzt, aber die Wahrscheinlichkeit, dass das Betriebssystem dies deaktiviert und das Programm jemals zurückkehrt, ist vernachlässigbar gering.

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

}

Hoffe das stürzt ab. Prost.

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

Eine stilvolle Möglichkeit hierfür ist ein rein virtueller Funktionsaufruf:

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

Zusammengestellt mit gcc, druckt dies:

reine virtuelle Methode aufgerufen

Beenden ohne aktive Ausnahme beendet

Abgebrochen (Core Dumped)

Sie können Assembly in Ihrem C ++ verwenden, code ABER INT 3 nur für x86-Systeme. Andere Systeme verfügen möglicherweise über andere Trap- / Breakpoint-Anweisungen.

int main()
{
    __asm int 3;

    return 0;
}

INT 3 verursacht einen Interrupt und ruft einen vom Betriebssystem eingerichteten Interrupt-Vektor auf.

Verwenden Sie __builtin_trap () in GCC oder clang oder __debugbreak () in MSVC. Wenn diese Haltepunkte / Traps nicht behandelt werden, führt dies zu einer nicht behandelten Haltepunktausnahme / einem Absturz. Andere Vorschläge, die abort () oder exit () verwenden: Diese können von anderen Threads verarbeitet werden, wodurch es schwieriger wird, den Stapel des Threads zu sehen, der den Absturz verbreitet hat.

char*freeThis;
free(freeThis);

Das Freigeben eines nicht initialisierten Zeigers ist ein undefiniertes Verhalten. Auf vielen Plattformen / Compilern freeThiswird ein zufälliger Wert angezeigt (was auch immer sich zuvor an diesem Speicherort befand). Wenn Sie es freigeben, wird das System aufgefordert, den Speicher an dieser Adresse freizugeben. Dies führt normalerweise zu einem Segmentierungsfehler und führt zum Absturz des Programms.