reiniciar - ¿Cuál es la forma más rápida de forzar el bloqueo de una aplicación de iOS?

como reiniciar iphone 8

Question

Estoy tratando de probar mis análisis de fallas. No me di cuenta de lo difícil que es hacer que una aplicación se cuelgue a voluntad. parece tan simple a mitad de la programación. ¿Alguien tiene alguna sugerencia sobre cómo forzaría mi aplicación a bloquearse? Y no me refiero a un pequeño crash de "error de memoria", es decir, el teléfono no sabe qué hacer consigo mismo. Necesito que al menos ingrese en los registros del dispositivo como un bloqueo, en el organizador de Xcode. ¿Alguna sugerencia?

Answer 1

¡Tantas formas de matar una aplicación! Aquí hay dos líneas de uno:

[self performSelector:@selector(die_die)];

además

@[][666];

Answer 2

A menudo me resulta útil hacer que la aplicación se inicie, haga algo por un tiempo y luego se cuelgue después de 10 segundos. En este caso (para Objective-C ), utilizo:

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

Un beneficio secundario para esto es que el compilador no arroja ninguna advertencia (si usa Objective-C) sobre el selector que no se encuentra. :)

Swift :

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

Answer 3

Creo que el buen índice de matriz fuera de rango es una garantía de "falla exitosa", así que aquí mi lista favorita:

Swift 4 :

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

Objective-C :

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

Aunque @throw NSInternalInconsistencyException; arregla su problema, es una excepción (no un bloqueo), por lo tanto, podría ser caught .

Answer 4

Por rápido, esto funcionó para mí:

assert(false, "sdf")

Y esto:

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

Answer 5

Simplemente escriba assert(NO) . Esto verifica la condición dada como parámetro y bloquea la aplicación si es falsa.

Editar:

exit(0) también hará el truco

Answer 6

Una forma más controlada sería tirar una excepción tú mismo:

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

Ver NSException.h para ver más excepciones.

Answer 7

*(long*)0 = 0xDEADBEEF;

Da un EXC_BAD_ACCESS

Answer 8

@throw NSInternalInconsistencyException;

Answer 9

int* p = 0;
*p = 0;

Da un EXC_BAD_ACCESS (code=2, address=0x0)

Editar:

Después de que Greg Parkers comentara que un compilador puede optimizar las afirmaciones anteriores, me hizo pensar más detenidamente sobre las afirmaciones anteriores, y por qué Greg Parker tiene razón:

De hecho, desreferenciar el puntero NULL es "comportamiento indefinido" en C y C ++ (ver también C99 §6.5.3.2 / 4).

Esto significa que el efecto de las declaraciones anteriores depende del compilador. Este "comportamiento indefinido" también significa que el compilador tiene permitido aplicar un par de optimizaciones, lo que puede tener el efecto de que las afirmaciones anteriores se "optimicen siempre", como afirma Greg Parker.

Bueno, ahora eso me hizo sentir curiosidad por lo que en realidad haría el clang:

Este es el pequeño programa de prueba:

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

con la optimización establecida en "-Our", obtenemos este desmontaje:

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

donde ud2 es un código de operación que significa "código de operación indefinido" y causa una excepción de CPU:

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

(Tal vez @GregParker puede comentar por qué clang elige este enfoque?)

Si bien esto es interesante, se refiere a "desreferenciar el puntero NULL" solamente. Si tenemos esto en su lugar:

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

el programa falla como se esperaba, pero requiere el "requisito previo" de que el hardware rechace las escrituras en esta dirección (no válida).