Mon application ne s'écrase que lorsque vous n'utilisez pas d'utilisation de xcode débogueur. Il était difficile de suivre parce que je ne peux pas déboguer mais je l'ai finalement compris. C'était à cause d'appeler la libération sur certains objets qui ne sont pas appartenant à moi. Avant de le corriger, j'ai cherché et j'ai trouvé 2 questions connexes ici (liens ci-dessous)
Aucune de la question ci-dessus n'a répondu pourquoi aucun crash lors de la course via débogger.so ma question est la raison pour laquelle cela se produit? Je connais des raisons de déboguer / publier des accidents spécifiques, mais c'est fou. Est-ce juste par hasard bien que cela soit arrivé plus de 10 fois.
6 Réponses :
Ce que vous décrivez n'est pas atypique des bugs liés à la mémoire obscurs. Vous voudrez peut-être aussi utiliser Debug-Malloc à des moments tels. Bien que cela ne soit pas garanti de tout trouver. La raison (et cela se produit probablement aussi longtemps qu'il y ait eu des debuggotes de niveau source) est que la mémoire est aménagée au moins quelque peu différemment dans le Code de débisibilité et lorsqu'il est en cours de marche sous le débogueur. Donc, l'erreur résulte d'une pièce de mémoire différente (sans danger) corrompue sous le débogueur. Lorsqu'il n'est pas sous le débogueur, l'emplacement corrompu est en fait quelque chose que votre code se soucie et s'écrase.
La même chose pourrait se produire en sens inverse, mais vous ne sauriez jamais - s'il s'écrase lorsqu'il est exécuté de manière débisible, vous le trouveriez avant de passer à l'exécution de l'environnement de débogage.
J'ai eu ce problème lors de l'accès aux bases de données SQLITE de l'extérieur du répertoire [[NSBUNDLE MAINBUNDUNDUNLET]], qui a provoqué des erreurs iCloud.
J'ai découvert l'erreur uniquement en installant une application de console sur mon iPhone qui a enregistré les erreurs.
Une fois que j'ai accédé aux bases de données du bon répertoire, les erreurs ont disparu et l'application démarré correctement.
L'application de console n'est plus disponible; Cette question était de 6 ans il y a 6 ans. Je supprimerai le lien mais ma réponse sur la lecture de bases de données à partir du répertoire incorrect reste toujours. Le bowvote me semble excessaire.
J'ai vécu ce symptôme lorsque j'ai fait une nstring, envoyé un utf8string de celui-ci à un autre objet et l'a attribué à un pointeur de caractère. Eh bien, il s'avère que j'ai oublié de conserver l'original Nstring, qui n'aurait pas important de toute façon, car je n'ai pas non plus compris que la méthode UTF8String (qui est vraisemblablement un objet qui donne accès au pointeur lui-même) fonctionne dans l'autorelease bassin. C'est-à-dire que la conservation de la nstring elle-même n'a pas corrigé le problème.
Je suppose que cela semblait fonctionner très bien lorsqu'il est attaché sous le débogueur uniquement parce que j'avais des zombies activés, de sorte que le pointeur que j'avais était toujours valable. Je devrais voir si c'est la raison pour laquelle cela fonctionnait; Si tel est le cas, c'est une bonne raison de tester avec et sans Nszombie activé.
En tout cas, c'était probablement un design médiocre pour commencer, et une jolie erreur de gestion de la mémoire débutante évidente une fois que j'ai trouvée. Heureusement, la console dans la fenêtre de l'organisateur m'a donné des indices sur où commencer à regarder et que le débogage m'a finalement montré où la valeur de mon pointeur changeait. J'espère que cela aide toute personne qui trouve le chemin ici.
J'avais aussi ce problème et j'ai eu la chance de comprendre la cause rapidement, espérons-le en postant ici, je peux sauver quelqu'un d'autre de temps perdu. Pour clarifier, mon application fonctionnerait sans problèmes lors du lancement directement à partir de Xcode, mais s'écraserait immédiatement lors de son lancement manuellement sur l'iPad.
L'application en question est écrite dans Obj-C mais repose sur un code tiers écrit à Swift. Le code SWIFT est inclus dans l'application en tant que cadre intégré. Je devais définir "Le contenu intégré contient un code SWIFT" sur Oui dans les paramètres de construction de l'application (sous Options de construction), puis le problème est parti.
Réitérant @ Jyoung de réponse depuis que je ne l'ai pas vu la première fois que j'ai jeté un coup d'œil:
Essayez de courir avec des objets zombies éteints.
En mode de débogage si vous l'avez allumé, il manipule une allocation de mémoire différemment. Essayez de le courir sans.
Aller au schéma d'édition ...> Exécuter> Diagnostics. Assurez-vous alors que les objets Zombie sont désactivés:
puis parcourez à nouveau votre chemin de code.
J'ai eu ce même problème tout en travaillant sur un projet modularisé avec des frameworks Xcode. Même après avoir retiré toute la logique de l'Appdelegate et ne renvoyant que VRAI Inside Inside Inside Application: DidfinishlaunchingwithOptions , j'avais toujours le crash. Ensuite, je suis passé à mes paramètres de projet, dans la section Cadres, Bibliothèques et Contenu Embedded et modifié l'option Intégré pour les frameworks que j'ai ajoutés à Incord & Sign>. C'était ce qui a résolu le problème pour moi. J'espère que quelqu'un trouvera cette utile.
J'ai eu un problème similaire. Dans mon cas, je n'avais pas lié un cadre qui faisait également partie de la stratégie de modularisation du projet. Étrangement, j'ai pu exécuter le projet via Xcode, mais pas directement à partir du simulateur, il s'est toujours écrasé lors du lancement. Ce qui était difficile était de suivre le cadre manquant, devait revenir à des engagements antérieurs pour trouver le coupable.
Avez-vous essayé de profiler avec des zombies activés?
Non mais je l'ai compris en cherchant à traiter la méthode de distribution que j'envoie un message de libération à un objet zombie.