Astuce pour debugger un problème d'autorelease pool
NeoPhoenix
Membre
Bonjour à tous,
je viens partager une petite astuce trouvée sur google hier concernant le debug d'un problème de gestion mémoire et d'autoreleasePool.
Mon problème était simple : j'avais un objet déjà releasé dans une autoreleasePool. Par contre le diagnostique peut s'avérer complexe : l'application plante au moment du pop de l'autoreleasePool, et gdb ne nous donne pour seule information l'adresse de l'objet qui a posé problème et en spécifiant que cette adresse est déjà libérée.
Pour résoudre ce casse tête, j'ai fait appel à mon meilleur ami : Google (oui je sais, nous sommes plusieurs à l'avoir comme meilleur ami ...) Voilà sa solution :
1. Ajoutez 2 variables d'environnement
- Allez dans : Project > Edit Active Executable
- Puis Arguments > Variables to be set in the environment
- Ajoutez MallocStackLoggingNoCompact et MallocStackLogging
(Ces deux variables ont pour but d'écrire dans un fichier temporaire les logs Malloc/Free)
2. Rejouez votre scénario jusqu'au crash
3. Après le crash, écrivez dans gdb : shell malloc_history <PID> <OBJECT_ADDRESS>
Vous verrez apparaà®tre tout l'historique de l'adresse posant problème. Le debug est ensuite beaucoup plus simple !
Est ce que quelqu'un a une autre méthode pour résoudre ce type de problèmes ? Peut être en utilisant Instruments ?
je viens partager une petite astuce trouvée sur google hier concernant le debug d'un problème de gestion mémoire et d'autoreleasePool.
Mon problème était simple : j'avais un objet déjà releasé dans une autoreleasePool. Par contre le diagnostique peut s'avérer complexe : l'application plante au moment du pop de l'autoreleasePool, et gdb ne nous donne pour seule information l'adresse de l'objet qui a posé problème et en spécifiant que cette adresse est déjà libérée.
Pour résoudre ce casse tête, j'ai fait appel à mon meilleur ami : Google (oui je sais, nous sommes plusieurs à l'avoir comme meilleur ami ...) Voilà sa solution :
1. Ajoutez 2 variables d'environnement
- Allez dans : Project > Edit Active Executable
- Puis Arguments > Variables to be set in the environment
- Ajoutez MallocStackLoggingNoCompact et MallocStackLogging
(Ces deux variables ont pour but d'écrire dans un fichier temporaire les logs Malloc/Free)
2. Rejouez votre scénario jusqu'au crash
3. Après le crash, écrivez dans gdb : shell malloc_history <PID> <OBJECT_ADDRESS>
Vous verrez apparaà®tre tout l'historique de l'adresse posant problème. Le debug est ensuite beaucoup plus simple !
Est ce que quelqu'un a une autre méthode pour résoudre ce type de problèmes ? Peut être en utilisant Instruments ?
Connectez-vous ou Inscrivez-vous pour répondre.
Réponses
Idem pour le break point de Xcode sur les exceptions, qui te permettent de remonter jusqu'à la méthode qui pose problème.