强制 iOS 应用程序崩溃的最快方法是什么？
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/21555813/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
What's the quickest way to force an iOS app to crash?
提问by Katushai
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?
我正在尝试测试我的崩溃分析。我没有意识到随意让应用程序崩溃是多么困难。中间编程似乎如此简单。有人对我如何强制我的应用程序崩溃有任何建议吗？我的意思不是一点“内存错误”崩溃，我的意思是手机不知道如何处理自己。我需要它至少在 Xcode 的管理器中作为崩溃进入设备日志。有什么建议？
回答by Stavash
@throw NSInternalInconsistencyException;
回答by fsaint
So many ways to kill an app! Here are two one liners:
杀死应用程序的方法有很多！这是两个合一的衬垫：
[self performSelector:@selector(die_die)];
also
还
@[][666];
回答by Levi
Just write assert(NO). This checks the condition given as parameter and crashes the app if it is false.
只是写assert(NO)。这会检查作为参数给出的条件，如果为 false，则应用程序崩溃。
Edit:
编辑：
exit(0)will also do the trick
exit(0)也会做的伎俩
回答by CouchDeveloper
int* p = 0;
*p = 0;
Gives a EXC_BAD_ACCESS (code=2, address=0x0)
给出一个 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:
在 Greg Parkers 评论说允许编译器优化掉上述语句之后，这让我更彻底地思考了上述语句，以及为什么 Greg Parker 是对的：
In fact, dereferencing the NULL pointeris "undefined behavior" in C and C++ (see also C99 §6.5.3.2/4).
事实上，在 C 和 C++ 中取消引用 NULL 指针是“未定义行为”（另请参见 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.
这意味着，上述语句的效果取决于编译器。这种“未定义的行为”也意味着允许编译器应用一些优化，这可能会导致上述语句被“优化掉”——正如 Greg Parker 断言的那样。
Well, now that made me curious what clang would actually do:
好吧，现在这让我很好奇 clang 实际上会做什么：
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:
优化设置为“-Ofast”，我们得到这个反汇编：
0x100000f90: pushq %rbp
0x100000f91: movq %rsp, %rbp
0x100000f94: ud2
where ud2is an opcode meaning "undefined opcode" and causes a CPU exception:
其中ud2是一个操作码，意思是“未定义的操作码”并导致 CPU 异常：
`EXC_BAD_INSTRUCTION (code=EXC_I386_INVOP, subcode=0x0)`
(Maybe @GregParker can comment why clang chooses this approach?)
（也许@GregParker 可以评论为什么 clang 选择这种方法？）
While this is interesting, it refers to "dereferencing the NULL pointer" only. If we have this instead:
虽然这很有趣，但它仅指“取消引用 NULL 指针”。如果我们有这个：
int* p = (int*)1;
*p = 0;
the program crashes as expected - but requires the "prerequisite" that the hardware refuses writes to this (invalid) address.
程序按预期崩溃 - 但需要硬件拒绝写入此（无效）地址的“先决条件”。
回答by Andrea Mugnaini
I think the good old array index out of range is a guarantee of "successful crash", so here my favourite list:
我认为好的旧数组索引超出范围是“成功崩溃”的保证，所以这里是我最喜欢的列表：
Swift 4:
斯威夫特 4：
[][0]fatalError()
[][0]fatalError()
Objective-C:
目标-C：
@[][0];int *x = nil; *x = 0;
@[][0];int *x = nil; *x = 0;
Although @throw NSInternalInconsistencyException;fixes your problem, is an exception (not a crash), hence might be caught.
虽然@throw NSInternalInconsistencyException;解决了您的问题，但它是一个例外（不是崩溃），因此可能会被捕获。
回答by ChrisJF
I often find it useful to have the application start up, do its thing for a bit, and then crash after 10 seconds. In this case (for Objective-C), I use:
我经常发现让应用程序启动，做一些事情，然后在 10 秒后崩溃很有用。在这种情况下（对于Objective-C），我使用：
[self performSelector:NSSelectorFromString(@"crashme:") withObject:nil afterDelay:10];
A secondary benefit to this is that the compiler doesn't throw any warnings (if using Objective-C) about the selector not being found. :)
这样做的第二个好处是编译器不会抛出任何关于未找到选择器的警告（如果使用 Objective-C）。:)
Swift:
斯威夫特：
self.perform("crashme:", with: nil, afterDelay: 10)
回答by ABeanSits
A more controlled way would be to actually throw an exception yourself:
一种更可控的方法是自己实际抛出异常：
@throw [NSException exceptionWithName:NSGenericException reason:@"" userInfo:nil];
@throw [NSException exceptionWithName:NSGenericException reason:@"" userInfo:nil];
Check NSException.hfor more exceptions.
检查NSException.h更多异常。
回答by Esqarrouth
For swift these worked for me:
对于 swift 这些对我有用：
assert(false, "sdf")
And this:
和这个：
var hey:[Int] = []
hey[0] = 1
回答by Antoine Rosset
*(long*)0 = 0xDEADBEEF;
Gives an EXC_BAD_ACCESS
给出 EXC_BAD_ACCESS
