6
votes

Guard Malloc a trouvé une erreur exc_bad_access instantanément. Pourquoi ne pas utiliser tout le temps?

J'ai débogué l'erreur infâme exc_bad_access pendant quelques jours maintenant. Nszombieenabled = Oui n'a rien offert. La pile d'appels était différente chaque fois que j'ai reçu l'erreur, qui était une fois tous les 5 ou 6 courses.

J'ai vu une astuce pour l'activation de Guard Malloc (qui se trouve dans l'éditeur de schéma pour Xcode 4) sur le site Web de Lou Franco: compréhension exc_bad_access . Dès que je l'ai fait, mon programme s'est arrêté sur la ligne exacte qui causait cette erreur insaisissable.

Selon sa description, Guard Malloc crée des pages séparées pour chaque MALLOC et supprime la page entière lorsque la mémoire est libérée, écrasant ainsi le programme lorsque la mémoire libérée est accessible. Pour le développement général, pourquoi ne ferais-je pas juste garder Guard Malloc en tout le temps? Il semble facilement attraper certains types d'erreurs de mémoire. Si je ne teste pas spécifiquement la gestion de la mémoire ou la performance, y a-t-il un peu d'inconvénient de l'utiliser?


0 commentaires

3 Réponses :


3
votes

allouer une page globale 4K pour quelques octets par MALLOC () gaspillage espace adresse très rapidement.


0 commentaires

7
votes

Cela ne gaspille pas seulement l'espace d'adresses, mais cela ralentira de manière significative votre programme (potentiellement au point où il est inutilisable, même sur le simulateur). Je suppose que pour un programme IOS lorsque vous l'exécutez sur le simulateur, c'est un peu discutable (la mémoire n'est pas un problème, et le succès de la performance n'est pas terrible non plus), mais peut-être au nom de la meilleure pratique que vous ne devriez pas courez-le constamment.


0 commentaires

2
votes

GuardMalloc fait une application courante beaucoup plus lente, surtout si vous avez un grand nombre d'allocations au cours de l'exécution normale. Je garde ça éteint la plupart du temps.

Je transforme GuardMallOCOC pour déboguer un crash qui mangue la pile. Souvent, ceux-ci ont objc_msgsend en haut de tout ce qui reste de la pile.

avec GuardMallOC, les effets aléatoires des pointeurs suspendus sont empêchés. L'adresse du pointeur ne peut pas être réutilisée et son emplacement de mémoire est invalide. L'accident se produira presque immédiatement, bien avant que la pile soit corrompue. C'est génial pour le code hérité C ++ ainsi que le nouvel objectif-c.

Je laisse les autres aides à débogage de la mémoire à temps plein.


0 commentaires