Fuites avec ABPeoplePickerView. Bug Apple?

Lio70

Membre expert
Club iGen
16 Janvier 2004
2 396
1 282
Bonjour,

Je vérifiais mon app avec Instruments et constate une douzaine de fuites de mémoire dont je ne comprenais pas précisément la cause, mais une a un rapport avec AddressBook. En isolant diverses fonctionnalites dans des mini-projets, je constate que toutes ces fuites sont causées par le simple affichage d'un ABPeoplePickerView sur la fenêtre principale d'une app, sans meme qu'aucune IBAction n'entre en jeu, et rien dans awakeFromNib. Donc fuites au lancement de l'app.

Je teste ensuite l'exemple de code dispo sur le site Apple "CocoaPeoplePicker" et je constate exactement les memes fuites avec ce code d'Apple.

S'agit-il d'un bug du framework AddressBook? Une incompatibilité avec l'environnement? (Xcode 4.3 / LLVM 3.1 / Lion 7.3).

J'ai aussi poste ce message sur le forum dev Apple.

a+

---------- Nouveau message ajouté à 13h20 ---------- Le message précédent a été envoyé à 11h36 ----------

Je viens d'avoir l'occasion de tester les apps (la mienne ainsi que le code exemple d'Apple) sur Snow Leopard et il n'y a pas de fuites. C'est donc un problème avec Lion.

Un de plus :rolleyes:

Mais y a-t-il un workaround, histoire d'avoir une app nickel ?
 
J'attendais d'avoir un retour d'autres developpeurs, soit ici soit sur le forum d'Apple, avant d'envoyer un bug report. Si pas de réponses, je le ferai demain.
 
J'attendais d'avoir un retour d'autres developpeurs, soit ici soit sur le forum d'Apple, avant d'envoyer un bug report. Si pas de réponses, je le ferai demain.

tu ne devrais pas etre aussi categorique instrument est souvent idiot avec les pool memoire et te marquera une fuite alors qu'elle n'existe pas, tu devrais plutot te baser sur la memoire reelle
 
J'ai encore fait quelques tests et le problème des leaks est vraiment sur Lion. En revanche, sur Snow, Instruments d'Xcode 4 se crashe parfois :p .

Je crois que je vais faire tourner le radar sur le forum Apple.

Rien dans la console debug d'Xcode et mon app tourne nickel. Ma crainte est la suivante: a cause de ces leaks, mon app peut-elle être refusée lors de la validation Mac AppStore ?
 
Je reviens un moment la-dessus car je retravaille cette application avec Xcode 4.4 GM sur Mountain Lion et, sans avoir modifie le code relatif a cette partie qui gere la sélection dans l'ABPeoplePickerView, je n'ai pas de leak dans Instruments. Donc c'etait vraiment sur Lion.

Autre chose qui fonctionnait bien avec Snow, ne fonctionnait plus avec Lion et fonctionne a nouveau bien avec Mountain: faire une app qui présente les Events et Reminders du CalendarStore. Quand je modifiais les donnees sur mon iPhone puis synchronisait avec le Mac, les modif apparaissent automatiquement dans mon app apres quelques secondes sous Snow. Cela ne marchait plus avec Lion, comme si le NotificationCenter ne réagissait pas (je devais quitte/relancer mon app pour voir le resultat des modifs). Et ca remarche de nouveau nickel avec Mountain.

Je me suis dit que c'etait du a mon usage du framework CalendarStore puisqu'Apple a decrete qu'il était "deprecated" en faveur d'EventKit. Mais si c'etait le cas, ca ne devrait pas tourner sur Mountain.

Independemment de ceci, je ne sais pas ce que les autres dev pensent de Mountain mais je trouve qu'OSX a bien progresse depuis Lion. Je recommande aux users de l'adopter rapidement des qu'il sortira.
 
c'est tout a fait possible que le probleme soit coté Apple Lion est une horreur sortie a la va vite, moi premiere fois que je repasse au systeme précedent pour pouvoir travailler e.g snow, vu l'experience avec vista pardon lion j'attend un peu, apres oui j'ai des différents boots pour tester moutain a l'air plus fini, mais pour travailler c'est pas encore ca, tu ne peux plus targeter 3/3gs c'est comme si tout le monde avait des nouveaux telephones, meme pas un an et zou, sur ce coup ils ne vont pas bien.
 
c'est tout a fait possible que le probleme soit coté Apple Lion est une horreur sortie a la va vite, moi premiere fois que je repasse au systeme précedent pour pouvoir travailler e.g snow, vu l'experience avec vista pardon lion j'attend un peu, apres oui j'ai des différents boots pour tester moutain a l'air plus fini, mais pour travailler c'est pas encore ca, tu ne peux plus targeter 3/3gs c'est comme si tout le monde avait des nouveaux telephones, meme pas un an et zou, sur ce coup ils ne vont pas bien.
Lion = Vista, c'etait aussi mon opinion.
Et Seven une version correcte et finie de Vista. Meme chose avec Mountain Lion: une version correcte et finie de Lion.
Par contre pour les iPhones, il n'y a aucun probleme a prendre en charge un 3GS (j'en ai un) avec une app sous Mountain. Tu veux dire que la limite sera au niveau de iOS6 ?
 
non ios 5.1, plus de target 4.3 c'est problematique sur 3g
et s pour certains composants presents mais font nada sur ces telephones, moralité c'est a passage forcé, je developpe pour ios4 et le reste n'a jamais existé c'est un peu fort apres seulement 8mois.
 
BANDE DE GUIGNOLS :D
Donner des conseils aux dev c'est bien. Se les appliquer a soi-meme c'est aussi bien.
Je parle d'Apple.

Je regardais recemment les sessions video de la WWDC 2012 et dans celle consacree au passage a la high-res (Retina), comment ajouter des bitmaps ou des icones high-res etc... ils disent qu'ils ne faut plus appeler les graphiques avec NSImage compositeToPoint dorenavant mais avec drawAtPoint.

Surprise, peut-etre a la faveur d'un changement de la meteo car je ne me souviens pas avoir update Mountain ni Xcode44 aujourd'hui (sauf update automatique a mon insu), voici que mon ABPeoplePicker qui ne genere plus de leak sous Mountain, genere maintenant un avertissement dans la console d'Xcode :

*** WARNING: -[NSImage compositeToPoint: operation:] is deprecated in MacOSX 10.8 and later. Please use -[NSImage drawAtPoint:fromRect: operation:fraction:] instead.
*** WARNING: -[NSImage compositeToPoint:fromRect: operation:] is deprecated in MacOSX 10.8 and later. Please use -[NSImage drawAtPoint:fromRect: operation:fraction:] instead.

Puisqu'il n'y a aucun code de ce type dans mon app, c'est bien l'objet ABPeopelPickerView qui est en cause.
 
Bien possible que la faute soit côté Apple en effet, j'aime pas trop leur jeter la pierre puisqu'ils fournissent quand même un SDK de très bonne qualité pour OS X et iOS, mais j'avoue que j'ai vraiment beaucoup de mal à les suivre par moments dans leur doc et leurs "best practices"... je dévie un peu, mais typiquement, les properties utilisées à toutes les sauces dans leurs exemples de codes pour iOS, je suis vraiment pas pour ; je sais pas si ils sont partis du principe qu'il valait mieux fournir des samples rapides à écrire que des trucs plus clean, mais ça m'a toujours un peu dérangé.
 
Dans mon message precedent j'ai l'air de conclure un peu trop vite mais je n'ai pas ecrit les tests que j'avais faits. Par exemple. Ajouter dans l'AppDelegate une instruction concernant NSContraint..blabla :

Bloc de code:
+ (void)initialize {
	NSUserDefaults * standardUserDefaults = [NSUserDefaults standardUserDefaults];

    [standardUserDefaults setBool:YES forKey:@"NSConstraintBasedLayoutVisualizeMutuallyExclusiveConstraints"];
}

Au moment du lancement de l'app, cela met en evidence les lignes/zones des objets graphiques (par exemple le TableView qui constitue l'interface du ABPeoplePickerView) avec des couleurs pour voir ou il y a des problemes. En cliquant sur ces lignes oranges et bleues, cela fait apparaitre le message d'erreur dans la console. Je me souviens de deux problemes:
- avec la scrollbar du TableView
- avec les limites des colonnes: "overlapping".

Donc c'est un defaut de conception dans l'objet.

Avec Lion, Apple a apporte des modifications a CoreGraphic mais a sans doute omis d'adapter l'objet ABPeoplePicker.

En ce qui concerne les "best practices" et la doc Apple, ce qui me frappe en regardant les sessions video des WWDC c'est par exemple:
Le gars d'Apple traite du sujet A et, dans sa demonstration, presente du code qui, a un certain endroit, releve d'un sujet B. Dans la session propre au sujet B, on apprend des best practices concernant ce sujet et on realise que le premier mec qui parlait du sujet A ne respectait pas lui-meme ces best practices pour le code qu'il a cree et qui ne relevait pas de son domaine. Donc pas de bonne communication entre les ingenieurs.
 
Dernière édition: