What's the quickest way to force an iOS app to crash?

Question

I'm trying to test my crash analytics. I didn't realize how hard it is to make an app crash at will. it seems so simple mid-programming. Does anybody have a suggestion as to how i'd force my app to crash? And i don't mean a little "memory error" crash, i mean the phone doesn't know what to do with itself. I need it to at the very least enter into the device logs as a crash, in Xcode's organizer. Any suggestions?

Solution 1

@throw NSInternalInconsistencyException;

Solution 2

So many ways to kill an app! Here are two one liners:

[self performSelector:@selector(die_die)];

also

@[][666];

Solution 3

Just write assert(NO). This checks the condition given as parameter and crashes the app if it is false.

Edit:

exit(0) will also do the trick

Solution 4

int* p = 0;
*p = 0;

Gives a EXC_BAD_ACCESS (code=2, address=0x0)

Edit:

After Greg Parkers comment that a compiler is allowed to optimize away the above statements, it made me think more thoroughly about the above statements, and why Greg Parker is right:

In fact, dereferencing the NULL pointer is "undefined behavior" in C and C++ (see also C99 §6.5.3.2/4).

This means, the effect of the above statements depend on the compiler. This "undefined behavior" also means, that the compiler is allowed to apply a couple of optimizations, which may have the effect that the above statements will be "optimized aways" - as Greg Parker asserts.

Well, now that made me curious what clang would actually do:

This is the small test program:

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

with optimization set to "-Ofast", we get this disassembly:

0x100000f90:  pushq  %rbp
0x100000f91:  movq   %rsp, %rbp
0x100000f94:  ud2    

where ud2 is an opcode meaning "undefined opcode" and causes a CPU exception:

`EXC_BAD_INSTRUCTION (code=EXC_I386_INVOP, subcode=0x0)`

(Maybe @GregParker can comment why clang chooses this approach?)

While this is interesting, it refers to "dereferencing the NULL pointer" only. If we have this instead:

int* p = (int*)1;
*p = 0;

the program crashes as expected - but requires the "prerequisite" that the hardware refuses writes to this (invalid) address.

Solution 5

I think the good old array index out of range is a guarantee of "successful crash", so here my favourite list:

Swift 4:

1. [][0]
2. fatalError()

Objective-C:

1. @[][0];
2. int *x = nil; *x = 0;

---

Although @throw NSInternalInconsistencyException; fixes your problem, is an exception (not a crash), hence might be caught.

View more solutions

Comments

[Katushai]

this method worked as well. i had to accept the other answer because it came first though. very nice. this seems like something most people wouldn't know would cause a crash on iOS

[Desdenova]

@Stavash By default no. But easy to do so. Check your target's build settings: Apple LLVM 5.0 - Preprocessing > Enable Foundation Assertions.

[Katushai]

this one worked. i accepted this answer because it came first, but assert(no) also worked. also i chose this one because it appears to be native to cocoa as opposed to C, so apple designed this for this specific reason (my guess)

[rmaddy]

A call to exit does not cause a crash.

[fsaint]

@maddy ... you are correct sir! thanks for making my score a multiple of 10. That extra 2 points was driving me nuts.

[rmaddy]

I didn't downvote. Someone else did. Don't make such assumptions.

[fsaint]

@maddy Sorry for blaming. Cheers!

[Greg Parker]

The compiler is allowed to optimize this away.

[Greg Parker]

The compiler is allowed to optimize this away.

[CouchDeveloper]

@GregParker True, but this is a different "problem" ;)

[CouchDeveloper]

Throwing an exception does not necessarily lead to a crash. If the exception will be caught, the program can proceed. If the exception will not handled, the system function terminate() will be called, which in turn calls abort(). That is, strictly, the program does NOT crash, but it terminates.

[Katushai]

termination resulted in a crash report to my analytics, so this worked for my purposes

[Katushai]

for the sake of completeness, i think it should be NSAssert, in true cocoa fashion. but it works either way

[Qix - MONICA WAS MISTREATED]

Please explain why your answer is the solution to the question.

[Esqarrouth]

i dont know why and dont really care. it crashes and does it with minimal code

[Qix - MONICA WAS MISTREATED]

You're an answerer, you should care.

[Esqarrouth]

well arrays dont work like that in swift, normally we should append inside the array at a selected index. since we are not using the normal method it crashes.

[Peter N Lewis]

Why not just call abort() directly then? Thrown exceptions can be caught - abort() cannot. On the Mac, abort() generates a crashlog, I presume it does on iOS as well.

[Stavash]

I'm not sure about how crash analytics SDKs work with abort(). The original question was for testing crash analytics services so a native @throw statement was my best guess.

[NaXir]

Its not crash its just an exception and results into troggering exc_breakpoint

[Jayprakash Dubey]

What does @[][666]; mean? could you explain?

[fsaint]

@[] is an empty array. 666 is the number of the unspeakable one. Any number would cause the crash, I chose 666 for dramatic value.