Ce qui est un moyen fiable de faire une application iOS crash?

Je veux tester mon application rapport d'incident dans le domaine délibérément l'avoir crash lorsque l'utilisateur effectue une action spécifique que d'un réel de l'utilisateur est peu probable de faire accidentellement.

Mais ce qui est un bon moyen fiable de faire de l'app crash qui n'est pas de créer une alerte au moment de la compilation?

Edit: Noter que de nombreux apparemment évidente à cette question des réponses suite à des exceptions que de se faire attraper par le Cacao et donc n'ont pas de résultats dans l'application crash.

Je suis WebKit discarded an uncaught exception pour toutes ces idées jusqu'à présent! Qui savait qu'il était si difficile de faire une appli crash ces jours-ci?
Je ne pense pas que l'un de ces n'a rien à voir avec WebKit...
Yep, ouvrez Safari sur un iPad 1 et accédez à une page avec beaucoup d'images. Fonctionne toujours pour moi. :/
(void)0/0;, (void)*(char*)0;
Soyez prudent avec certaines des réponses ici invoquant undefined behavior. C'est effectivement très méchant conseils!!!
Par définition, un essai est une tentative d'invoquer un comportement indéfini.
très méchant, des conseils parce que, théoriquement, il pourrait causer à l'application pour faire autre chose que de l'écraser? Pas vraiment méchant, est-il?
C++ comportement indéfini est plus complexe que cela. Voir blog.regehr.org/archives/213 Undefined signifie que la violation d'accès n'est pas garanti. Au lieu de cela, le compilateur peut-il suffit de supprimer le code arbitrairement par exemple.
pas du tout. Un comportement indéfini est un C/C++ concept. Vous ne voulez jamais il. Voir blog.regehr.org/archives/213

InformationsquelleAutor Nestor | 2012-11-22

138

en Objective-C C directement à cause d'un mauvais accès
```
strcpy(0, "bla");
```
Note: bien que cela fonctionne sur n'importe quel système je sais -- dans une future version du runtime C OU le compilateur cela pourrait ne pas conduire à un crash plus. voir Est déréférencement de pointeur null comportement indéfini en Objective-C?)

(en swift que vous auriez à pont à objC pour ce faire)
- c'est à mon humble avis le moyen le plus fiable
- Ah oui, c'est le WebKit discarded an uncaught exception problème aussi.
- il y avait une faute de frappe encore 😀 n @"bla", mais "bla"
- Est déréférencement de pointeur null comportement défini en Objective-C?
- Apparemment (stackoverflow.com/questions/13651642/...), c'est un comportement indéfini et en fait une très mauvaise réponse! Le compilateur peut légalement optimiser à la fois des états et ne rien faire. Je vous suggère de supprimer cette réponse. Elle peut amener les gens à le faire.
- Ainsi, le compilateur peut inline de la méthode et de déterminer que le pointeur déréférencé sans condition. Qui déclenche un comportement indéfini. Cela vaut pour toute fonction pure à tous, pas seulement pour la fonction strcpy. le compilateur peut toujours coup d'oeil à l'intérieur. Tout comme un être humain.
- sur ios et osx et windows et redhat, il a toujours écrasé ainsi, dans le contexte donné, je dirais que la validité de son. Je vais ajouter un avertissement
- Cela fonctionne parfaitement en 2016 avec macOS Sierra et Xcode 8 simulateurs.
InformationsquelleAutor Daij-Djan
95

Mon chouchou:
```
assert(! "crashing on purpose to test <insert your reason here>");
```
Un classique:
```
kill( getpid(), SIGABRT );
```
Et certains pr0n:
```
*(long*)0 = 0xB16B00B5;
```
Tous générer des plantages capturé par mon crash de l'outil de reporting.
- affirmer ne crash pas sur les autres versions, c'est pourquoi il est une assertion
- cela dépend de vos paramètres de construction; aussi, je pense que la question est à propos des tests, il semble ok pour garder affirme dans les versions de test
- Beaucoup de gens (y compris moi) laisser affirme dans les versions release. Il n'y a pas de raison de les désactiver.
- la taille et la performance peut-être?
- La taille ne devrait pas être un problème. La Performance peut-être dans les jeux.
- est une fonctionnalité de débogage, n'a guère de sens de laisser ces trucs dans les versions release. Il y a des tests unitaires pour que.
- Affirme ne sont pas uniquement une fonctionnalité de débogage. De la même manière que vous pourriez argument que vous ne devriez pas vérifier les paramètres et de les jeter IllegalArgumentException en Java. Je le répète, il n'y a pas de raison de les supprimer. Voir aussi stackoverflow.com/questions/8481396/...
- À mon humble avis assert n'est pas une fonctionnalité de débogage. Un échec de l'affirmer, c'est un bug que vous avez pensé impossible. Il est préférable d'abandonner, même un communiqué de construire, de maintenir l'exécution d'un programme avec des conséquences imprévisibles.
- Je suis d'accord avec cette réponse, et je pense que c'est celui de l'OP devrait avoir accepté. assert signifie exactement ce que l'OP est en demandant: "Cela ne doit jamais arriver". Laissant une assertion de travail dans un communiqué de construire n'est pas difficile et il n'y a rien de mal à le faire.
- "Cela ne doit jamais arriver" est très différent de "je ne peux pas récupérer de cette condition", donc l'assertion n'est pas toujours le meilleur des cas, pour attraper les erreurs imprévisibles. Il y a des exceptions à cela. Aussi, affirme ne pas traiter avec des fichiers ouverts.
- Je ne connais pas les détails, mais assert(0) pourrait mettre fin à plus gracieusement qu'un mauvais accès. Pour tester des rapports d'incidents correctement, je veux quelque chose d'aussi méchant comme un réel bug imprévu.
- Voir stackoverflow.com/questions/13651642/.... Le déréférencement de pointeur nul est un comportement indéfini, et peut faire quoi que ce soit. Y compris celui d'être optimisé à!
InformationsquelleAutor djromero
26

Depuis que nous utilisons tous Clang pour iOS, c'est assez fiable:
```
__builtin_trap();
```
Cela a l'avantage qu'il est conçu pour exactement cet effet, de sorte qu'il ne devrait pas générer les avertissements du compilateur ou d'erreurs.

InformationsquelleAutor Dietrich Epp
24

abort(); provoque un arrêt anormal... C'est un accident.
- developer.apple.com/library/mac/documentation/Darwin/Reference/...
InformationsquelleAutor kmkaplan
20

Comment sur un bon débordement de pile 🙂
```
- (void)stackOverflow
{
    [self stackOverflow];
}
```
- Meilleure réponse pour stackoverflow.com. Upvoted.
InformationsquelleAutor Taum
16

Plus populaire - non comptabilisé sélecteur de crash:
```
NSObject *object = [[NSObject alloc] init];
[object performSelector:@selector(asfd)];
```
Assurez-vous que vous n'avez pas -fasd méthode mise en œuvre dans la classe haha

Ou de l'indice au-delà lié exception:
```
NSArray * array = [NSArray array];
[array objectAtIndex:5];
```
Et bien sûr
kill( getpid(), SIGABRT );

InformationsquelleAutor wirrwarr
9

Envoyer un message à un désalloué objet
- C'est en fait très peu fiables. Vous pouvez encore envoyer des messages à désalloué objets aussi longtemps que leur mémoire n'est pas réutilisé. C'est la raison pour laquelle les gens ont toujours eu très difficiles à déboguer double libération des erreurs. C'est seulement lorsque la mémoire est récupérée par un autre objet que l'envoi d'un message peut provoquer une exception.
InformationsquelleAutor Andrey Chernukha
9

Je pense que dans Swift, vous pouvez facilement lancer une erreur fatale:
```
func foo() {
    fatalError("crash!")
}
```
Il est en fait même l'intention d'utiliser cette fonction dans le cas où quelque chose va mal, afin de rendre l'application crash.

Pour éviter une instruction if dans un cas particulier, vous pouvez utiliser precondition, trop. Il est similaire à la assert, fait donc l'intention (si voulu) assez clair et est pas supprimé dans la version finale assert. Il est utilisé comme precondition(myBoolean, "This is a helpful error message for debugging.").

InformationsquelleAutor borchero
7
```
exit(0);
```
(doit... type... 30 caractères)
- Merci pour les upvotes mais en fait, cela rendra l'application de résilier et de retour au Tremplin, qui, même si elle peut être utile en lui-même, n'est-ce pas ce que l'OP voulait, qui est de déclencher une exception non interceptée
InformationsquelleAutor Steve Rogers
6

Vous pouvez également déclencher une exception:
```
[NSException raise:NSInternalInconsistencyException
            format:@"I want to test app crashes!."];
```
- Je ne pense pas que l'exception est que la bonne façon, la capture de l'exception est commun de sorte que vous pourriez accidentellement de l'attraper. La capture de signaux n'est pas si courant si mauvais accès ou des choses semblables seraient plus fiables. 🙂
InformationsquelleAutor Alessandro Vendruscolo
3

Ajouter un geste de reconnaissance à vue, il reconnaît une 10 doigts (5 doigts pour iPhone 10 pouvez obtenir un peu de monde). La GR est une méthode attaché à ce que l'exécute n'importe qui de le mentionné précédemment moyens infaillibles pour obtenir de votre application à l'écrasement. La plupart des utilisateurs ne vont pas pondre 10 doigts vers le bas sur votre application, donc vous êtes sûrs de l'utilisateur accidentellement à l'origine du crash.

Cependant, vous devriez être en mesure d'utiliser quelque chose comme Testflight ou tout simplement de le déployer sur les appareils personnels et de test dans la nature avant de les soumettre à Apple. Après avoir forcé un crash pouvait obtenir votre application rejetée par Apple.
- Mon Cocos2d application se bloque quand je fais une extrême multi touch, et j'ai ça comme un bug non résolu. Je n'ai pas de GR, mais j'ai activé le multitouch dans Cocos2d. Dois-je l'expérience de l'incident que vous décrivez? Tu veux dire que ce qui est attendu/voulu comportement?
- Je ne pense pas que vous êtes crash que vous décrivez est prévu (OMI accidents ne doit jamais être prévu et personnellement, je ne pense pas que c'est une bonne idée de dessein de les mettre dans votre application pour cette question). Vous pouvez essayer de symbolicating de l'accident, et de savoir exactement ce que la méthode est à l'origine de l'application crash. Il pourrait être quelque chose à l'intérieur de la Cocos2d cadre qui est à l'origine du crash lorsque l '"extrême multi-touch' se produit. Si c'est le cas, alors votre meilleur pari est le dépôt d'un bug avec le Cocos2d les gars.
InformationsquelleAutor jhelzer
2

pourrait essayer quelque chose comme
```
NSArray* crashingArray = [NSArray arrayWithCapacity:1];
[crashingArray release];
```
devrait bloquer sur une EXC_BAD_ACCESS (peut-être besoin de libérer une deuxième fois, mais normalement il devrait planter comme ça déjà)
- L'habitude de compiler avec l'ARC activé.
- eh bien, si ouy utilisation de l'ARC, vous pourriez aussi le faire : NSArray* crashingArray = [NSArray arrayWithCapacity:1]; [crashingArray objectAtIndex:0]; ce devrait être de s'écraser
InformationsquelleAutor Saliom
1

Je vais aller avec:int raise(int sig);

Pour obtenir plus d'infos >man raise

InformationsquelleAutor Vytautas
0

Je voudrais juste tuer le processus normalement:
```
kill(getpid(), SIGKILL);
```
Donc, si vous installez un gestionnaire de signal vous pouvez également gérer l'accident, à la finition et à écrire les fichiers ouverts et de ces choses.
- c'est déjà inclus dans la madmw réponse
InformationsquelleAutor Ramy Al Zuhouri
0

- Je utiliser
```
[self doesNotRecognizeSelector:_cmd]; 
```
- Ce poste est automatiquement marqué comme étant de faible qualité, car c'est le seul code. Auriez-vous l'esprit de l'élargir en y ajoutant du texte pour expliquer pourquoi cela résout le problème?
InformationsquelleAutor Duyen-Hoa
0

Lorsque l'on travaille avec RubyMotion j'utilise ceci:
```
    n=Pointer.new ('c', 1)
    n[1000] ='h'
```
InformationsquelleAutor Raymond

Essayez ceci:

- (IBAction)Button:(id)sender
{
    NSArray *array = [NSArray new];
    NSLog(@"%@",[array objectAtIndex:8]);
}

InformationsquelleAutor Rajesh Loganathan

-1

un mauvais NSLog déclaration il
```
NSLog(@"%@",1);
```
InformationsquelleAutor Mutawe

Vous devez vous connecter pour publier un commentaire.