HomeProductsDownloadOrderSupportSearch
  
 
 Myriad Blog 1.3.0 Friday, Mar 29th, 2024 at 02:02pm 

Thursday, Feb 24th, 2022 at 05:01pm
macOS et porosité

 
La porosité ou fuite de mémoire (leak) des applications est un problème sérieux.
C’est dans les systèmes d’exploitation modernes une des dernières erreurs d’une application qui peut affecter d’autres applications.
Quand une application a besoin de mémoire elle en demande au système.
Elle est tenue de libérer cette mémoire.
S'il y a des oublis de libération, la taille mémoire allouée à l’application va enfler, le système va essayer de compenser en basculant une partie de la mémoire réelle en mémoire virtuelle (sur disque) d’où des ralentissements et à terme des blocages généraux de l’ordinateur.
 
Heureusement des outils sont fournis pour pouvoir vérifier en temps réel ce qui se passe. Sur macOS c’est le « Moniteur d’activité »
Il nous a permis de diagnostiquer des pertes de mémoire sur nos applications et nous avons passé plusieurs jour à comprendre ce qui se passait.
 
A bout d’idées, nous nous sommes posés la question de savoir si le problème ne venait pas du système lui-même. Cela nous a paru tellement étrange que nous avons décidé de mener des tests sur une application fournie par le système : Textedit.
Voici le protocole :
- on lance Textedit
- on note la mémoire allouée
- on ouvre/ferme très rapidement des fenêtres en maintenant la touche Pomme enfoncée et en faisant N W N W….
- on regarde la différence de mémoire
 
Et là on se rends compte que de la mémoire n’est jamais libérée !
 
Ce test a été mené sur 10.7, 10.11, 10.14 et finalement sur la dernière version du système 12.2.1
 

 
Voici ce que l’on obtient avec Textedit, toute fenêtre fermée :
 

 
Et après le test d’ouverture et fermeture multiples :
 

 
Donc soit la perte de mémoire est effective, soit c’est l’outil d’inspection qui donne un résultat erroné.
 
Nous avons alors décidé de tenter d’isoler la fonction système soupçonnée d’être poreuse.
 
Pour afficher une image nous utilisons la séquence :
- création de l’image (et donc allocation de mémoire)
- affichage de l’image
- libération de l’image (et donc libération de la la mémoire)
 
Si l’on supprime l’affichage et gardons les autres opérations la fuite disparait.
 
Ce serait donc dans notre cas  la fonction CGContextDrawImage qui n’est pas « propre » et qui entraine des fuites.
 
A suivre…
by Didier Guillion


Most recent first
Oldest first

Top of page
Legal information Cookies Last update:  (c) Myriad