Qual é a maneira mais fácil de travar um programa C ++?

Estou tentando criar um programa Python que faça interface com um processo travado diferente (que está fora do meu alcance). Infelizmente, o programa com o qual estou interagindo nem falha de maneira confiável! Então, eu quero criar um programa C ++ rápido que trava de propósito, mas na verdade eu não sei a melhor e mais curta maneira de fazer isso, alguém sabe o que colocar entre os meus:

int main() {
    crashyCodeGoesHere();
}

fazer meu programa C ++ travar de maneira confiável

A abort()função é provavelmente a sua melhor aposta. Faz parte da biblioteca padrão C e é definido como "causando o encerramento anormal do programa" (por exemplo, um erro fatal ou falha).

Experimentar:

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

Encontrado em:

#include <signal.h>

Dividir por zero irá travar o aplicativo:

int main()
{
    return 1 / 0;
}

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

Bem, estamos com excesso de pilha , ou não?

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

(Não há garantia de falha por nenhum padrão, mas nenhuma das respostas sugeridas, incluindo a aceita, já que SIGABRTpoderia ter sido detectada de qualquer maneira. Na prática, isso falhará em todos os lugares.)

 throw 42;

Apenas a resposta ... :)

assert(false); também é muito bom

De acordo com a ISO / IEC 9899: 1999, é garantido um travamento quando o NDEBUG não está definido:

Se NDEBUG for definido, [...] a macro assert é definida simplesmente como

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

A macro assert é redefinida de acordo com o estado atual do NDEBUG cada vez que é incluído.

[...]

A macro assertiva coloca testes de diagnóstico em programas; se a expressão (que deve ter um tipo escalar) é falsa [...]. Em seguida, chama a função abortar.

Como uma falha é um sintoma de invocar um comportamento indefinido e, uma vez que a invocação de um comportamento indefinido pode levar a qualquer coisa, incluindo uma falha, não acho que você queira realmente travar seu programa, mas apenas deixá-lo cair em um depurador. A maneira mais portátil de fazer isso é provavelmente abort().

Embora raise(SIGABRT)tenha o mesmo efeito, certamente é mais para escrever. No entanto, as duas maneiras podem ser interceptadas instalando um manipulador de sinais para SIGABRT. Portanto, dependendo da sua situação, você pode querer / precisar gerar outro sinal. SIGFPE, SIGILL, SIGINT, SIGTERMOu SIGSEGVpode ser o caminho a percorrer, mas todos eles podem ser interceptadas.

Quando você pode não ser portável, suas escolhas podem ser ainda mais amplas, como usar SIGBUSno linux.

O único flash que tive foi a função abort () :

Ele interrompe o processo com uma finalização anormal do programa. Gera o sinal SIGABRT , que por padrão faz com que o programa finalize retornando um código de erro de finalização malsucedido ao ambiente host. O programa é finalizado sem executar destruidores para objetos de duração de armazenamento estático ou automático , e sem chamar nenhuma função atexit (chamada por exit () antes do programa terminar)). Ele nunca retorna ao chamador.

A resposta é específica da plataforma e depende de seus objetivos. Mas aqui está a função de travamento do Mozilla Javascript, que eu acho que ilustra muitos dos desafios para fazer esse trabalho:

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
}

Vejo que há muitas respostas postadas aqui que caem em casos de sorte para concluir o trabalho, mas nenhuma delas é 100% determinística para travar. Alguns travam em um hardware e sistema operacional, outros não. No entanto, existe uma maneira padrão, conforme o padrão oficial do C ++, de fazê-lo falhar.

Citando a norma C ++ ISO / IEC 14882 §15.1-7 :

Se o mecanismo de tratamento de exceções, após concluir a inicialização do objeto de exceção, mas antes da ativação de um manipulador para a exceção, chamar uma função que sai por meio de uma exceção, std :: terminate será chamado (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) { }
}

Eu escrevi um pequeno código para demonstrar isso e pode ser encontrado e testado no Ideone aqui .

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

A ISO / IEC 14882 §15.1 / 9 menciona o lançamento sem o bloco try, resultando em uma chamada implícita para abortar:

Se atualmente nenhuma exceção está sendo manipulada, a execução de uma expressão de lançamento sem operando chama std :: terminate ()

Outros incluem: lançamento do destruidor: ISO / IEC 14882 §15.2 / 3

*( ( char* ) NULL ) = 0;

Isso produzirá uma falha de segmentação.

Este está faltando:

int main = 42;

E o estouro de pilha por uma chamada de método recursivo de loop morto?

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

Consulte Exemplo original no Microsoft KB

Isso trava no meu sistema Linux, porque literais de seqüência de caracteres são armazenados na memória somente leitura:

0[""]--;

A propósito, o g ++ se recusa a compilar isso. Compiladores estão ficando cada vez mais inteligentes :)

int i = 1 / 0;

Seu compilador provavelmente o alertará sobre isso, mas compila muito bem no GCC 4.4.3 Isso provavelmente causará um SIGFPE (exceção de ponto flutuante), que talvez não seja tão provável em um aplicativo real quanto o SIGSEGV (violação de segmentação de memória) como as outras respostas causam, mas ainda é um acidente. Na minha opinião, isso é muito mais legível.

Outra maneira, se vamos trapacear e usar signal.h, é:

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

Isso é garantido para eliminar o subprocesso, para contrastar com o SIGSEGV.

Esta é uma versão mais garantida do cancelamento apresentada nas respostas acima. Ele cuida da situação em que o sigabrt está bloqueado. Você pode usar qualquer sinal em vez de cancelar que tenha a ação padrão de travar o programa.

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

Isso também deve travar. No Windows, ele trava com o AccessViolation e deve fazer o mesmo em todos os sistemas operacionais, eu acho.

Este é o trecho fornecido pelo Google no 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;
}

Embora esta pergunta já tenha uma resposta aceita ...

void main(){
    throw 1;
}

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

A gravação em uma memória somente leitura causará uma falha de segmentação, a menos que seu sistema não suporte blocos de memória somente leitura.

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

Eu testei com o MingGW 5.3.0 no Windows 7 e o GCC no Linux Mint. Suponho que outros compiladores e sistemas tenham um efeito semelhante.

Ou de outra maneira, já que estamos no vagão da banda.

Uma adorável peça de recursão infinita. Garantido para explodir sua pilha.

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

Imprime:

falha de segmentação (despejo de núcleo)

Um que ainda não foi mencionado:

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

Isso tratará o ponteiro nulo como um ponteiro de função e depois o chamará. Assim como a maioria dos métodos, não é garantido que isso interrompa o programa, mas as chances do sistema operacional permitir que isso ocorra e que o programa volte sempre são insignificantes.

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

}

Espero que isso trava. Felicidades.

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

Uma maneira elegante de fazer isso é uma chamada de função virtual pura:

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

Compilado com o gcc, ele imprime:

método virtual puro chamado

terminar chamado sem uma exceção ativa

Abortado (núcleo despejado)

Você pode usar a montagem em seu c ++, code mas INT 3 é apenas para sistemas x86 outros sistemas podem ter outras instruções de interceptação / ponto de interrupção.

int main()
{
    __asm int 3;

    return 0;
}

INT 3 causa uma interrupção e chama um vetor de interrupção configurado pelo sistema operacional.

Use __builtin_trap () no GCC ou clang, ou __debugbreak () no MSVC. O não manuseio desses pontos de interrupção / interrupções levará a uma exceção / falha não tratada do ponto de interrupção. Outras sugestões que usam abort () ou exit (): podem ser tratadas por outros threads, dificultando a visualização da pilha do thread que propagou a falha.

char*freeThis;
free(freeThis);

Liberar um ponteiro não inicializado é um comportamento indefinido. Em muitas plataformas / compiladores, freeThisterá um valor aleatório (o que estava naquele local da memória antes). A liberação solicitará que o sistema libere a memória nesse endereço, o que geralmente causará uma falha de segmentação e causará uma falha no programa.