Clang pour traquer les fuites mémoires...
Mala
Membre, Modérateur
En me baladant sur le blog de Jeff LAMARCHE, je suis tombé par hasard sur l'un de ses derniers posts qui parle de Clang:
http://iphonedevelopment.blogspot.com/2009/02/clang-static-analyzer.html
Depuis le temps que je cherchais un outil efficace pour traquer les fuites mémoires! Je viens de tester sur un gros projet et je dois dire qu'il est rusé le bougre.
C'est vraiment un "must have" du développeur Cocoa.
http://iphonedevelopment.blogspot.com/2009/02/clang-static-analyzer.html
Depuis le temps que je cherchais un outil efficace pour traquer les fuites mémoires! Je viens de tester sur un gros projet et je dois dire qu'il est rusé le bougre.
C'est vraiment un "must have" du développeur Cocoa.
Connectez-vous ou Inscrivez-vous pour répondre.
Réponses
[Edit] Ah, j'avais pas vu, ça analyse le code avant compilation
Oui, du coup tu as une analyse plus fine des problèmes et cela ne se limite pas aux fuites mémoires. C'est vraiment complémentaire avec Instrument.
Clang GUI
On dézippe, on lance, on glisse un projet xcode dans la zone de dépot, on fait run et on attend que ça se passe... Une fois l'analyse terminée, si il y a des erreurs dans le code, l'appli lance une page web générée par Clang avec tous les soucis qu'on avait pas vu.
PS: Testé sous Xcode 3.1.2/Intel/OSX 10.5.
Edit: modification pour pointer vers la page web de Clang GUI
[Edit] apparemment, ouais... mais :
Can't exec "clang": No such file or directory at /Users/schlum/Desktop/Clang GUI.app/Contents/Resources/scan-build line 94.
scan-build: Cannot execute 'clang'
Je viens de mettre à jour le zip. En toute logique je pense que c'est ok maintenant.
Suggestion d'amélioration : passer par une WebView pour tout avoir dans la même appli !
j'avais une semaine de développement sur un projet sans avoir fait particulièrement de vérification, et ben ça gagne du temps !
: J'obtiens 3 messages sur une méthode - (CGPathRef)quartzPath; , du code "copié-collé" dans la doc d'Apple !
On continue les tests... Si plusieurs projets dans la directory :
J'ai aussi fait quelques modifs mineures :
- mémorisé le dernier projet déposé.
- remplacé la suppression bête et méchante du répertoire build par un "xcodebuild clean" comme ça je nettoie aussi les dépendances.
Donc ça normalement c'est vu avec la dernière version. Je fais un clean avant de lancer Clang sinon il ne repasse pas en revue les fichiers précédemment traités.
Edit: A non pardon, toi c'est plusieurs projets au même endroit. je vais regarder ça car effectivement, par défaut je donne le répertoire du projet en paramètre.
J'essaie en virant les 2 autres :P
PS : au passage, tu devrais mettre la NSTextView non éditable... Je me suis planté en glissant le projet, je l'ai glissé dessus
Je t'ai ajouté l'option "xcodebuild -project [nom du projet]" cela devrait résoudre ton cas je pense.
J'ai testé avec deux projets différents, mais ça affiche toujours le premier rapport !
J'ai été chercher le bon dans le dossier temp/
Boulette en modifiant le code sur le clean des répertoires. Autant pour moi, c'est corrigé. :fouf):
Vu dans la foulée.
Mais c'est qu'ils sont exigeant en plus!!! :P
Je n'ai pas testé mais apparement pour le C++ c'est pas très avancé (activé?).
Plus d'infos ici...
C++ Support in Clang
Sinon je viens de mettre au propre une petite page web pour le GUI...
Page Clang GUI
Edit: Apparement l'option n'est pas encore reconnue par la commande scan-build hors c'est elle qui se charge d'appeler Clang derrière.
Bravo pour le reste
Une remarque : CLang est sensible au nom pris pour les méthodes. Dans un projet assez conséquent, j'avais mis copy dans le nom d'une méthode d'une catégorie et cette méthode renvoyait le résultat en autorelease, CLang m'a gratifié d'un leak en raison de la convention de nommage . Instruments lui ne donnait pas de leak lors de l'exécution.
1) Je change le nom, et le leak disparaà®t
2) Je réessaye dans un mini-petit-projet d'essai la même méthode avec le nom contenant copy, CLang a sans doute possibilité de vérifier plus avant ma méthode, et là je n'ai pas d'indication de leak ...
Mais je confirme que c'est un bel outil qui m'a détecté quelques dealloc non faits, quelques variables qui traà®naient inutilement, ... évitant la relecture pas à pas de chaque fichier.
Je viens de faire le test et ca marche bien chez moi. As-tu bien fais là mise à jour suite à la remarque de mpergand?
J'ai téléchargé Clang GUI depuis ton site web dont tu donnes l'URL plus haut.
J'ai testé un projet iPhone... mais il refuse de compiler, pour la simple et bonne raison que je n'ai pas de certificat (code-signing), en effet jusqu'à présent je ne développe que sur iPhone Simulator...
Je n'ai pas trouvé dans ton programme où régler les options de compilations (tu semblais au fil de ce post dire avoir rajouté des réglages possibles ?), donc en particulier comment lui demander d'utiliser les réglages Debug-Simulator ou Release-Simulator  pour compiler plutôt que ceux pour le Device ? Pourtant quand j'ouvre mon projet avec Xcode la configuration active est bien "Debug - Simulator"...
Sinon j'ai testé sur un projet OSX, et il termine par ceci (et reste sur l'onglet "Build", il ne va pas sur "Result" qui de toute façon est vide) : C'est normal qu'il n'y ait pas de rapport de build ? Ca veut dire que mon projet n'a aucune erreur ou risque de leak et donc que tout va bien ?
Sinon interface épurée... ce qui est bien... mais un peu trop je trouve :
- Le fait qu'il n'y ait pas de menu Fichier, et en particulier par de possibilité de faire Pomme-O pour choisir un projet (on est obligé d'utiliser le drag&drop, ce qui est bien mais pas toujours la manière la plus adéquate), je trouve ça dommage ça me gêne un peu
- Pas de possibilité de choisir justement la configuration active du projet à utiliser pour la compilation
PS : Détail super important qui tue : je trouve que le bouton "Run" est vachement près du bord bas-droite de la fenêtre, j'ai pas l'impression que tu as respecté les "marges" que précaunise Apple dans ses Guidelines et que IB te suggère ? ^^
C'est vrai que sur les projets iPhone que j'ai testé j'ai un certificat valide. Je vais regarder ça.
J'ai ajouté des paramètres que je passe à la commande scan-build mais effecitvement ce serait bien de pouvoir paramètrer au moins le sdk dans le cas d'un projet l'iPhone. Par défaut, il doit se caler sur Device ce qui peut poser problème.
Oui, c'est que c'est tout bon pour lui.
Et bien voilà encore un peu de boulot. J'espère que j'aurais au moins droit à une tournée! :P
J'ai téléchargé sur le site après ce post
Je réessaye ...
Par contre, mon test avec copy que j'ai affiné, montre c'est vraiment le nom qui est pris en compte pour déterminer si la valeur envoyée est en autorelease ou en mode retain.
Ci-joint le test (commenter/décommenter ...)
- Menu fichier dispo.
- ajout d'une combo pour choisir le sdk iPhone pour les projets iPhone (Je détecte automatiqueemnt dans le projet xcode si j'ai affaire à un projet Mac ou iPhone et je rajoute l'option qui va bien lors du run).
A priori, j'ai trouvé un vieux projet avec un certificat erroné et ça semble ok. Merci de me confirmer chez vous.
NB: pour lister les sdk, je considère uniquement une installation standard dans /Developper et je scanne le répertoire "/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/".
J'ai ouvert Clang GUI, il avait gardé en mémoire le dernier projet que j'ai analysé, un projet OSX. Du coup le menu combo en bas était grisé.
J'ai fait glisser un projet iPhone à la place... le menu déroulant en bas ne s'est pas dégrisé.
J'ai dû quitter Clang GUI et le relancer pour que le menu soit dispo... j'imagine que tu ne fais le test qu'une fois, à l'ouverture de ton app, et non à chaque fois qu'on fait glisser un nouveau projet ?
Sinon une fois que j'ai pu choisir le SDK, la build du projet iPhone a bien fonctionné
(L'idéal serait de détecter le SDK utilisé pour le projet, qui doit sans doute être stocké qqpart dans le xcodeproj, mais bon)
Ensuite comme il m'avait détecté des erreurs (cf plus bas, bien ce clang) je les ai corrigées... il m'a dit "a pu d'erreurs", mais dans l'onglet "Result" en effet la webView contenait encore l'ancien rapport ! Faudrait la vider à chaque relance de "Run" :P
Après, le bouton "Run" mis par défaut (activable par la touche Entrée quoi) voire même un menuitem "Run" dans le nouveau menu Fichier avec le raccourci Pomme-R ou Pomme-B associé, serait idéal pour parfaire la chose...
--
Sinon bien ce petit clang : il m'a détecté des erreurs comme quoi j'avais oublié de releaser dans le dealloc une variable d'instance déclarée comme @property(retain)... Or en effet dans dealloc j'ai pas [tt][monivar release];[/tt] mais j'ai mis comme à mon habitude [tt]monivar = nil;[/tt]... donc je pensais qu'il avait pas tilté et que c'était une fausse alerte... jusqu'à ce que je réalise que je n'avais pas mis le "self." devant... donc en écrivant comme ça en effet il n'appelle pas le setter ! En mettant [tt]self.monivar = nil[/tt], hop, bug disparu Merci clang !