Какой самый быстрый способ заставить приложение iOS сбой?

Question

Я пытаюсь проверить свою аналитику крушения. Я не понимал, как сложно сделать атаку приложения по своему усмотрению. это кажется таким простым средним программированием. Кто-нибудь имеет предложение о том, как я могу заставить приложение сбой? И я не имею в виду небольшую ошибку «ошибка памяти», я имею в виду, что телефон не знает, что делать с собой. Мне нужно, чтобы он, по крайней мере, вошел в журналы устройств в качестве сбоя, в организаторе Xcode. Какие-либо предложения?

Answer 1

@throw NSInternalInconsistencyException; 

Answer 2

Просто напишите assert(NO). Это проверяет условие, заданное как параметр, и приводит к сбою приложения, если оно ложно.

Edit:

exit(0) также сделать трюк

Answer 3

более контролируемым способом был бы на самом деле бросить исключение себя:

@throw [NSException exceptionWithName:NSGenericException reason:@"" userInfo:nil];

Проверьте NSException.h больше исключений.

Answer 4

Так много способов убить приложение! Вот два один лайнеры:

[self performSelector:@selector(die_die)]; 

также

@[][666]; 

Answer 5

int* p = 0; 
*p = 0; 

дает EXC_BAD_ACCESS (code=2, address=0x0)

Edit:

После Greg Parkers комментарий о том, что компилятор позволил оптимизировать прочь вышеупомянутые заявления, это сделало меня думаю, что более подробно об этих заявлениях, и почему Грег Паркер прав:

В самом деле, разыменования указателя NULL является «неопределенное поведение» в C и C++ (см также C99 §6.5.3.2/4).

Это означает, что приведенные выше утверждения зависят от компилятора. Это «неопределенное поведение» также означает, что компилятору разрешено применять несколько оптимизаций, что может привести к тому, что вышеуказанные утверждения будут «оптимизированы», как утверждает Грег Паркер.

Ну, теперь, когда меня интересно, что лязг бы на самом деле:

Это небольшая тестовая программа:

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

с оптимизацией, установленным в «-Ofast», мы получаем эту разборку:

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

где ud2 это код операция означает «неопределенный» опкод и вызывает исключение процессора:

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

(Возможно, @GregParker может комментировать, почему clang выбирает этот подход?)

Хотя это интересно, оно относится только к «разыменованию указателя NULL». Если мы вместо этого:

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

программа падает, как и ожидался, - но требуют «предпосылки», что аппаратное обеспечение отказывается записывают данные (недействительный) адрес.

Answer 6

*(long*)0 = 0xDEADBEEF; 

Дает EXC_BAD_ACCESS

Answer 7

Для быстры они работали для меня:

assert(false, "sdf") 

И это:

var hey:[Int] = [] 
hey[0] = 1 

Answer 8

Я часто бывает полезно иметь приложение запускается, сделайте свое дело немного, а затем сработайте через 10 секунд. В этом случае (для Objective-C), я использую:

[self performSelector:NSSelectorFromString(@"crashme:") withObject:nil afterDelay:10]; 

Второе преимущество этого является то, что компилятор не выдает никаких предупреждений (при использовании Objective-C) о селекторе не найден , :)

Swift:

self.perform("crashme:", with: nil, afterDelay: 10) 

Answer 9

Я думаю, что хороший старый индекс массива вне диапазона является гарантией успешного "аварии", так вот мой любимый список:

Swift 4 :

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

Objective-C:

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

---

Хотя @throw NSInternalInconsistencyException; исправляет проблему, является исключением (не авария), следовательно, может быть caught.