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

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

Ответ 1

@throw NSInternalInconsistencyException;

Ответ 2

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

[self performSelector:@selector(die_die)];

@[][666];

Ответ 3

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

Edit:

exit(0) также выполнит трюк

Ответ 4

int* p = 0;
*p = 0;

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

Edit:

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

Фактически, разыменование указателя NULL есть "undefined поведение" в C и С++ (см. также C99 §6.5.3.2/4).

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

Итак, теперь мне стало интересно, что на самом деле сделал clang:

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

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 - это код операции "undefined код операции" и вызывает исключение ЦП:

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

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

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

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

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

Ответ 5

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

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

Второе преимущество заключается в том, что компилятор не бросает никаких предупреждений о том, что селектор не найден.:)

Ответ 6

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

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

Проверьте NSException.h для получения дополнительных исключений.

Ответ 7

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

assert(false, "sdf")

И это:

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

Ответ 8

*(long*)0 = 0xDEADBEEF;

Предоставляет EXC_BAD_ACCESS