I'm trying to make a Python program that interfaces with a different crashy process (that's out of my hands). Unfortunately the program I'm interfacing with doesn't even crash reliably! So I want to make a quick C++ program that crashes on purpose but I don't actually know the best and shortest way to do that, does anyone know what to put between my:

I nelieve whether or not this terminates is implementation-defined...
–
Oliver CharlesworthDec 12 '11 at 22:54

1

It's more than just implementation-defined -- the signal can be caught with signal(). Most sane applications don't, though.
–
duskwuffDec 12 '11 at 22:56

10

It will crash in exactly the same way as a normal SIGSEGV within the application (which is the way most applications crash). It is well defined what it does (by default it exits the application and generates a core file). Yes you can set a handler, but if you have one don't you want to test that in the same way!!
–
Loki AstariDec 13 '11 at 4:11

1

+1 for raise(). This lets you test for a ton of different types of exceptions by just changing the argument.
–
AlexWebrDec 13 '11 at 5:06

This one works across most languages.
–
Jesse AldridgeDec 16 '11 at 6:44

9

Depending on how clever your compiler is this will be caught at compile time. I know that visual studio 2008 won't compile this for c++ or c#.
–
AidanOJan 3 '12 at 16:05

Since this code is subject to constant folding it will not be even be compiled successfully so we cannot here say it can crash anything since you'll not have executable to run.
–
ArturApr 4 '12 at 14:31

"But which sane OS doesn't stop an application that tries to access memory at address 0?" -- That isn't really what you want to ask, but I'll answer anyway. In some computers there is RAM at address 0, and it is perfectly meaningful for a program to store a value there. A more meaningful question would be "Which OS doesn't stop an application that access memory at the address that a C++ implementation reserved for a null pointer?" In that case I don't know of any. But the original program is about the C++ language not about OSes.
–
Windows programmerDec 13 '11 at 7:41

24

Although this isn't guaranteed to crash, it is one of the most common kinds of crash in C++. So if you want to simulate a crash, this is an "authentic" way to do it :)
–
Chris Burt-BrownDec 13 '11 at 10:03

(Not guaranteed to crash by any standards, but neither are any of the suggested answers including the accepted one since SIGABRT could have been caught anyway. In practice, this will crash everywhere.)

I can see that being funny on a system with non protected code pages and you overwrite your program with some code that is accidentally an infinite loop that does nothing. Highly highly highly highly unlikely but potentially possible.
–
Loki AstariDec 13 '11 at 17:32

@Loki: What if it just read from every 4000th byte? Would that be less likely to crash? Definitely less dangerous.
–
Mooing DuckDec 13 '11 at 17:43

@MooingDuck: I am just making a funny comment. Don't take it that seriously :-) But it would be interesting if somebody found a a sequence of instructions that did something funny.
–
Loki AstariDec 13 '11 at 17:52

1

@LokiAstari: you're absolutely right. I was thinking about (&i)[i] += !i instead, but I feared the compiler might be clever enough and want to optimise that out. :-)
–
sam hocevarDec 13 '11 at 17:54

Since a crash is a symptom of invoking undefined behaviour, and since invoking undefined behaviour can lead to anything, including a crash, I don't think you want to really crash your program, but just have it drop into a debugger. The most portable way to do so is probably abort().

While raise(SIGABRT) has the same effect, it is certainly more to write. Both ways however can be intercepted by installing a signal handler for SIGABRT. So depending on your situation, you might want/need to raise another signal. SIGFPE, SIGILL, SIGINT, SIGTERM or SIGSEGV might be the way to go, but they all can be intercepted.

When you can be unportable, your choices might be even broader, like using SIGBUS on linux.

I really doubt that he wants a debugger involved. He seems to want to test what happens when the caller of a crashing program gets a crash sent his way. Which is very reasonable.
–
Donal FellowsDec 13 '11 at 18:03

The answer is platform specific and depends on your goals. But here's the Mozilla Javascript crash function, which I think illustrates a lot of the challenges to making this work:

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
}

It aborts the process with an abnormal program termination.It generates the SIGABRT signal, which by default causes the program to terminate returning an unsuccessful termination error code to the host environment.The program is terminated without executing destructors for objects of automatic or static storage duration, and without calling any atexit( which is called by exit() before the program terminates)function. It never returns to its caller.

"What will happen instead?" -- Anything could happen instead. Behaviour is undefined, so the implementation could assign 0 to one of your program's variables, or it could assign 42 to one of your program's variables, or it could format your hard drive and continue executing your program.
–
Windows programmerDec 13 '11 at 7:38

5

(continuing "Windows programmer" set of mind) It can make you computer explode, or it may cause it to come a live and take over the humanity. or... it will crash in 99.9% and it's defined as "undefined behavior" because no one wants to take responsibility on it.
–
Roee GavirelDec 14 '11 at 6:38

Actually, that's not guaranteed to even do undefined behaviour - it could completely defined and work properly. Consider this code: pastebin.com/WXCtTiDD (Tested on Linux as root, you could do this as a non-root user too if you do some config changes wiki.debian.org/mmap_min_addr)
–
cha0siteJun 14 '12 at 18:35

Your compiler will probably warn you about this, but it compiles just fine under GCC 4.4.3
This will probably cause a SIGFPE (floating-point exception), which perhaps is not as likely in a real application as SIGSEGV (memory segmentation violation) as the other answers cause, but it's still a crash. In my opinion, this is much more readable.

The C++ language does not guarantee that 1 / 0 will cause a SIGFPE. Behaviour is undefined. The implementation could say the result is 42.
–
Windows programmerDec 13 '11 at 5:09

1

@Windows programmer: The point is what undefined means. If I have a partial function f : A -> B, and f(a) is undefined for some a in A, then computing f(a) cannot return a value in B: either f(a) does not terminate or it returns some special value outside of B. Returning some random value b in B makes f(a) defined by f(a) = b, i.e. does not compute f as it was specified (f(a) MUST be undefined). So computing 1 / 0 cannot return a number because 1 / 0 is undefined on both integer and real numbers. IMO using undefined behaviour (i.e. anything will do) is not the correct approach here.
–
GiorgioDec 13 '11 at 9:21

@Giorgio if the hardware doesn't have some way of trapping it automatically you still force compilers to emit at least two instructions, one of which would be a branch too. That's approximately doubling the cost of a division. Everybody pays that cost like that. If it's optional and you want it you can always use a library function for it still. If it's not optional and you don't want it you'd still end up paying the cost.
–
Flexo♦Dec 13 '11 at 10:09

2

@Giorgio: I have an application that does a 100,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,‌​000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,0‌​00,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,00‌​0,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000‌​,000,000,000 * 10^1000000 divisions. I know for a fact that 0 of these will be a division by zero though there is no way the compiler can know this. I definitely do not want the compiler to plant the check for a division by zero.
–
Loki AstariDec 17 '11 at 6:44

This is a more guaranteed version of abort presented in above answers.It takes care of the situation when sigabrt is blocked.You can infact use any signal instead of abort that has the default action of crashing the program.

This will treat the null pointer as a function pointer and then call it. Just like most methods, this is not guaranteed to crash the program, but the chances of the OS allowing this to go unchecked and of the program ever returning are negligible.

I know several machines that this will cause a re-boot as the OS startup code is effectively mapped to the address 0. Don't assume that everything will work like your PC. You could say that was a crash but it is not very useful as you can not debug it as all state is wiped at startup.
–
Loki AstariDec 13 '11 at 20:15

@Loki Astari: I will none the less say that this is a crash -- if this can cause it, then the program being debugged may as well, meaning it's as good a test as any. On the other hand, I am curious which of these machines can run Python.
–
Anton GolovDec 13 '11 at 23:34

I think you missed the point. I have seen OS code at 0. Does not mean there are not systems with normal good code to run that will work just fine at 0. Or the bytes at 0 could just as easily be the opcode for return.
–
Loki AstariDec 14 '11 at 17:39

I am aware of OS code at 0; that's one of the reasons I strongly doubt that the bytes at 0 would be the opcode for return. The program is quite clearly not executing any more, and did not exit in the usual way, i.e. it crashed -- if this is not good enough for the asker, I expect him to comment on it himself.
–
Anton GolovDec 14 '11 at 17:57

1

You are aware of the OS code for your machine only. What I am trying to say is that it may fail for you. But that means nothing. There are lots of systems out there. I am sure that some of them this may work (i.e. as in not crash). Relying on machine/OS specific behavior is a bad idea and causes maintenance problems in the long run. The idea of the site is to promote good code (not just code that sort of works).
–
Loki AstariDec 14 '11 at 18:00

Calling main yourself is actually undefined behavior, in case you didn't know :) Also, tail recursion is not guaranteed to blow your stack. If you want a "guarantee", you have to do something after the recursive call, otherwise the compiler could optimize the recursion into an infinite loop.
–
fredoverflowSep 27 '12 at 5:53

Standard says you are not allowed to call main doing so is an invalid program. It could potentially do lots of other stuff.
–
Loki AstariDec 14 '11 at 17:40

@Loki Astari: The point of this program is it consumes all stack space. Just add some "return 0" or warp up another no-return function can also do this. I compile this code with "gcc a.c" and it just gave me the a.out:)
–
NybbleDec 15 '11 at 3:25

The point is that calling main() is invalid so weather it consumes stack space or not is unknowable (as it is undefined behavior). Any other function and your point will hold.
–
Loki AstariDec 15 '11 at 5:21

It's not valid: Because the standard explicitly states you can't call main: 3.6.1 Main function [basic.start.main] Paragraph 3: <quote>The function main shall not be used within a program.</quote> PS. This is a question about C++ not C a completely different language.
–
Loki AstariDec 15 '11 at 16:05

It would be great to have some clarification :)
–
olyvSep 17 '14 at 8:06

1

the p pointer will go beyond the program's address space which will be a memory error, as a process cannot access another process's memory. This will result the program to crash. pointer p is pointing to a random location in its address space, if it is incremented and dereferenced infinitely at some point it will point to another program's(process) address space. so it will crash after some time.
–
sc_csSep 17 '14 at 10:26

Or, hypothetically it could achieve integer overflow and wrap around, running infinitely. I'd try to use long long or size_t and start with p at the respective maximum value, or close to it, to crash faster. Though it's still not guaranteed to crash even in that case.
–
Patrick RobertsJun 23 at 0:42