Quelle est la façon la plus simple de faire planter un programme C ++?

J'essaie de créer un programme Python qui s'interface avec un autre processus brutal (c'est hors de ma portée). Malheureusement, le programme avec lequel je m'interface ne plante même pas de manière fiable! Je veux donc créer un programme C ++ rapide qui se bloque exprès, mais je ne connais pas vraiment la meilleure et la plus courte façon de le faire, est-ce que quelqu'un sait quoi mettre entre mes:

int main() {
    crashyCodeGoesHere();
}

faire planter mon programme C ++ de manière fiable

La abort()fonction est probablement votre meilleur choix. Il fait partie de la bibliothèque standard C et est défini comme «provoquant une fin anormale du programme» (par exemple, une erreur fatale ou un crash).

Essayer:

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

Trouvé dans:

#include <signal.h>

Si vous divisez par zéro, l'application se bloquera:

int main()
{
    return 1 / 0;
}

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

Eh bien, sommes-nous en débordement de pile , ou non?

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

(Il n'est pas garanti de planter selon les normes, mais aucune des réponses suggérées, y compris celle acceptée, car elle SIGABRTaurait pu être interceptée de toute façon. En pratique, cela plantera partout.)

 throw 42;

Juste la réponse ... :)

assert(false); est assez bon aussi.

Selon ISO / IEC 9899: 1999, il est garanti de se bloquer lorsque NDEBUG n'est pas défini:

Si NDEBUG est défini, la macro [...] assert est définie simplement comme

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

La macro d'assertion est redéfinie en fonction de l'état actuel de NDEBUG chaque fois qu'il est inclus.

[...]

La macro assert place les tests de diagnostic dans les programmes; [...] si l'expression (qui doit avoir un type scalaire) est fausse [...]. Il appelle ensuite la fonction d'abandon.

Puisqu'un crash est un symptôme d'invocation d'un comportement non défini, et puisque l'invocation d'un comportement non défini peut conduire à n'importe quoi, y compris un crash, je ne pense pas que vous vouliez vraiment planter votre programme, mais faites-le simplement tomber dans un débogueur. La façon la plus portable de le faire est probablementabort() .

Bien que cela raise(SIGABRT)ait le même effet, c'est certainement plus à écrire. Les deux manières peuvent cependant être interceptées en installant un gestionnaire de signaux pour SIGABRT. Donc, selon votre situation, vous voudrez peut-être / devrez lever un autre signal. SIGFPE, SIGILL, SIGINT, SIGTERMOuSIGSEGV peut - être la voie à suivre, mais ils peuvent tous être interceptés.

Lorsque vous ne pouvez pas être transférable, vos choix peuvent être encore plus larges, comme l'utilisation SIGBUSsur Linux.

Le seul flash que j'ai eu est la fonction abort () :

Il interrompt le processus avec une fin de programme anormale.Il génère le signal SIGABRT , qui par défaut provoque la fin du programme renvoyant un code d'erreur de fin infructueuse à l'environnement hôte.Le programme est terminé sans exécuter de destructeurs pour les objets de durée de stockage automatique ou statique et sans faire appel à tout atexit (qui est appelé par la sortie () avant que se termine le programme) fonction. Il ne revient jamais à son appelant.

La réponse est spécifique à la plateforme et dépend de vos objectifs. Mais voici la fonction de crash de Mozilla Javascript, qui, je pense, illustre beaucoup de défis pour faire fonctionner cela:

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
}

Je vois qu'il y a beaucoup de réponses publiées ici qui tomberont dans des cas chanceux pour faire le travail, mais aucune d'entre elles n'est 100% déterministe pour planter. Certains tomberont en panne sur un matériel et un système d'exploitation, d'autres non. Cependant, il existe un moyen standard selon la norme C ++ officielle de le faire planter.

Citant de la norme C ++ ISO / IEC 14882 §15.1-7 :

Si le mécanisme de gestion des exceptions, après avoir terminé l'initialisation de l'objet exception mais avant l'activation d'un gestionnaire pour l'exception, appelle une fonction qui se termine via une exception, std :: terminate est appelé (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) { }
}

J'ai écrit un petit code pour le démontrer et je peux le trouver et l'essayer sur Ideone ici .

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

L'ISO / CEI 14882 §15.1 / 9 mentionne un lancer sans bloc d'essai entraînant un appel implicite à l'abandon:

Si aucune exception n'est actuellement gérée, l'exécution d'une expression de lancement sans opérande appelle std :: terminate ()

Autres: jet du destructeur: ISO / IEC 14882 §15.2 / 3

*( ( char* ) NULL ) = 0;

Cela produira un défaut de segmentation.

Celui-ci manque:

int main = 42;

Qu'en est-il du débordement de pile par un appel de méthode récursive en boucle morte?

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

Voir l' exemple d'origine sur Microsoft KB

Cela se bloque sur mon système Linux, car les littéraux de chaîne sont stockés en mémoire morte:

0[""]--;

Soit dit en passant, g ++ refuse de compiler cela. Les compilateurs deviennent de plus en plus intelligents :)

int i = 1 / 0;

Votre compilateur vous avertit probablement à ce sujet, mais il compile très bien sous GCC 4.4.3 Ce sera probablement provoquera un SIGFPE (exception à virgule flottante), ce qui n'est peut-être pas aussi probable dans une application réelle que SIGSEGV (violation de segmentation de mémoire) que les autres réponses causent, mais c'est quand même un crash. À mon avis, c'est beaucoup plus lisible.

Une autre façon, si nous allons tricher et utiliser signal.h, est:

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

Ceci est garanti pour tuer le sous-processus, contrairement à SIGSEGV.

Il s'agit d'une version plus garantie de l'abandon présentée dans les réponses ci-dessus.Elle prend soin de la situation lorsque sigabrt est bloqué.Vous pouvez en fait utiliser n'importe quel signal au lieu d'abandonner qui a pour effet par défaut de planter le programme.

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

Cela devrait également planter. Sous Windows, il se bloque avec AccessViolation et il devrait faire de même sur tous les systèmes d'exploitation, je suppose.

Il s'agit de l'extrait fourni par Google dans 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;
}

Bien que cette question ait déjà une réponse acceptée ...

void main(){
    throw 1;
}

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

L'écriture dans une mémoire en lecture seule entraînera une erreur de segmentation, sauf si votre système ne prend pas en charge les blocs de mémoire en lecture seule.

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

Je l'ai testé avec MingGW 5.3.0 sur Windows 7 et GCC sur Linux Mint. Je suppose que d'autres compilateurs et systèmes donneront un effet similaire.

Ou d'une autre manière puisque nous sommes dans le wagon du groupe.

Un joli morceau de récursion infinie. Garanti pour faire exploser votre pile.

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

Imprime:

Segmentation fault (core dumped)

Celui qui n'a pas encore été mentionné:

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

Cela traitera le pointeur nul comme un pointeur de fonction, puis l'appellera. Tout comme la plupart des méthodes, cela ne garantit pas le plantage du programme, mais les chances que le système d'exploitation laisse cela sans contrôle et que le programme revienne jamais sont négligeables.

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

}

J'espère que ça plante. À votre santé.

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

Une façon élégante de le faire est un appel de fonction virtuelle pure:

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

Compilé avec gcc, ceci imprime:

méthode virtuelle pure appelée

terminer appeler sans exception active

Abandonné (core dumpé)

Vous pouvez utiliser l'assemblage dans votre c ++ code MAIS INT 3 c'est uniquement pour les systèmes x86 que d'autres systèmes peuvent avoir d'autres instructions d'interruption / point d'arrêt.

int main()
{
    __asm int 3;

    return 0;
}

INT 3 provoque une interruption et appelle un vecteur d'interruption configuré par le système d'exploitation.

Utilisez __builtin_trap () dans GCC ou clang, ou __debugbreak () dans MSVC. Le non-traitement de ces points d'arrêt / interruptions entraînera une exception / panne de point d'arrêt non gérée. Autres suggestions qui utilisent abort () ou exit (): celles-ci peuvent être gérées par d'autres threads, ce qui rend plus difficile la visualisation de la pile du thread qui a propagé le crash.

char*freeThis;
free(freeThis);

La libération d'un pointeur non initialisé est un comportement non défini. Sur de nombreuses plates-formes / compilateurs, freeThisaura une valeur aléatoire (ce qui se trouvait auparavant à cet emplacement mémoire). Le libérer demandera au système de libérer la mémoire à cette adresse, ce qui provoquera généralement une erreur de segmentation et fera planter le programme.