Accéder au contenu principal

malloc: xzm: failed to initialize deferred reclamation buffer



Lorsque je lance une de mes applications avec Xcode sur mon iPhone .... J'ai ce message de début :

 malloc: xzm: failed to initialize deferred reclamation buffer (46)

 Et franchement, je n'aime pas avoir des message que je ne comprends pas et qui contiennent le mot "failed" ! Mais le message n'existe pas avec mon iPad IOS16. Donc, ok, malloc je connais, on parle de la fonction de base d'allocation de mémoire système, il y a pleins d'outils pour les problèmes d'allocation mémoire, "xzm" doit être un de ces outils. Je ne trouve rien sur internet ! RIEN ! Perplexity ou Claude ne savent pas non plus ce que c'est. Je suis obligé de faire des suppositions...

XZ est un format de compression conçu pour remplacer BZIP qui est conçu pour remplacer GZIP qui est conçu pour remplacer Z. Peut-être que les données de debug de Xcode transitent en étant compressé par défaut ? Allons voir dans le schéma du projet, pour voir les options concernant les malloc :

Rien ne parle de xzm, mais parcourons les options :

Malloc Scribble

Cette option permet de corriger deux problèmes. Le premier est la non initialisation de l'espace mémoire allouée. Par défaut, malloc met des zéros dans l'espace mémoire, or zéro est souvent une valeur valide pour des données. On ne voit pas, lorsque l'on regarde la mémoire, qu'il y a un problème. Malloc Scribble va donc remplir la mémoire avec des 0x55 à la place de 0x00... La valeur 0x55 devient un indicateur qu'il y a un problème d'initialisation.

Malloc Scribble remplit aussi la mémoire de 0xAA lorsque la mémoire est libérée et ne doit plus être utilisée. Lorsque l'on écrase une mémoire qui contient des 0xAA, on doit donc immédiatement se poser la question d'un "free" qui ne devrait pas être là. De même si on "free" une zone remplie de 0xAA, c'est qu'il y a un "free" de trop.

Malloc Guard Edges

Cette option remplace le malloc/free par une version qui ajoute des plages de données avant et après la mémoire clouée, ces plages sont marquée inaccessible et font plantée l'application. Ainsi si le programme essaie de lire ou d'écrire en dehors de l'espace alloué, il y aura un plantage et le debuggeur saura de quel malloc il s'agît. Cette option s'ajoute à la suivante.

Guard Malloc

Cette option remplace le malloc/free par une version qui alloue la mémoire dans une plage entière (la mémoire est gérée par le système par bloc de 4Ko). Cela permet de désalouer toute la plage au moment du free et de faire planté l'application si elle essaie d'accéder à une plage qui a été libérée.

Guard Malloc prend énormément de mémoire et ralentie beaucoup l'application (uniquement en début évidemment). Un Malloc(100) n'alloue pas 100 octets, mais une plage de 4Ko, plus deux plages de 4Ko (avant et après la plage allouée) si l'option Malloc Guard Edge" est activée.

Zombie Objects

La gestion de l'allocation mémoire pour les objets a ses propres méthodes, il y a notamment un compteur d'utilisation de l'objet qui permet à l'application de savoir quand le supprimer de la mémoire. Avec cette option, lorsque le compteur arrive à zéro, l'objet n'est pas supprimé, ce qui permet, si le compteur d'utilisation est touché alors qu'il est à zéro, de savoir qu'on essai d'utiliser un objet qui ne devrait plus exister.

Malloc Stack Logging

Permet d'avoir un journal des allocations et libération mémoire.

Concluons

Mais revenons à nos moutons, le message d'erreur qui me gène disparaît si on active l'option "Malloc Scribble", et uniquement celle-ci. Les autres options s'activent, mais n'enlève pas le message d'erreur.

Ma console de debug affiche maintenant :

malloc: enabling scribbling to detect mods to free blocks

C'est mieux, cela n'explique pas vraiment le problème, mais c'est mieux. L'option Malloc Scribble ne prend pas de mémoire supplémentaire et ne coûte pas grand chose en terme de vitesse et ajoute une fonctionnalité intéressante. Donc c'est un compromis qui me va. 

Peut-être que la compression XZ est particulièrement efficace avec des zéros, et qu'elle n'est pas utilisée avec l'option "Malloc Scribble" qui enlève les zéros... 

Commentaires

Posts les plus consultés de ce blog

Tailles d'écran et iTunesConnect

 Lorsque l'on crée une nouvelle application, nous devons inclure des photos d'écran dans l'interface d'iTunes Connect :      Pour l'iPad, ce n'est pas bien compliqué, c'est indiqué, : Il faut les photos d'écran d'un iPadPro 12,9 pouce de 6ème (sans bouton home) et de 2e génération (avec le bouton home). Mais pour les iPhone c'est plus problématique, car il n'est indiqué que la taille de l'écran, et pas le modèle de l'appareil. Or dans la sélection des simulateurs, il n'y a pas les tailles des écrans des différent modèles ! Il faut donc se renseigner ici ;-) Appareil Taille iTunes Connect iPhone Pro Max 12, 13 6,7” Optionnel iPhone 11 Pro Max 6,5” Obligatoire iPhone 11, 12, 13 iPhone Pro 12, 13 6,1” iPhone X 5,8” iPhone 6+, 6S+, 7+, 8+ 5,5” Obligatoire iPhone 6, 6S, 7, 8 4,7” iPhone 5, 5S, SE 4” iPhone 4s 3,5” Personnellement, je ne savais pas que l'iPhone 11 Pro Max était le seul iPhone avec un écran 6,5 pouces !

Les bases de la programmation : Le binaire

Le binaire ”Ce monde est un code binaire où nous avons seulement deux options : accepter ou refuser. ” Ardit BEQIRI Lorsque l’on parle d’ordinateur on dit très souvent que ce n’est qu’un outil qui traite des 0 et 1, et ce n’est pas faux. Si l’on résume un ordinateur à de l’électronique, effectivement la mémoire, le processeur, les périphériques peuvent se résumer à des suites binaires, donc des suites de 0 et de 1. Mais c’est comme dire que le cerveau n’est qu’un imbroglio de neurones, c’est réducteur. La complexité du système est tel que l’on peut oublier qu’à la base c’est un système binaire, du reste un utilisateur d’ordinateur n’a même pas à savoir comment cela fonctionne, et même un programmeur n’a pas toujours à le savoir. Cependant, tous les langages informatiques comprennent une partie binaire. Et donc la compréhension du binaire est essentielle à un moment ou à un autre. En fait il y a plusieurs sujets interconnectés, la logique binaire, les opérations binaires, les nombr

xCode: auto-incrémentation du BUILD_VERSION

 Lorsque vous envoyez votre application à Apple, vous devez mettre à jour deux valeurs, le numéro de version et le numéro de build : Pour le numéro de Version, ce n'est pas vraiment un problème puisque celui-ci n'augmente que lors d'une mise à jour sur l'appStore. Cela peut être fait à la main. Pour le numéro de Build, c'est plus embêtant. Si vous êtes comme moi, et que vous faites de nombreuses bêta, il faut mettre à jour le numéro à chaque envoi de l'app, et on oublie souvent d'incrémenter la valeur. Le plus simple est alors d'incrémenter automatiquement la valeur à chaque compilation. Ainsi plus besoin de s'en occuper. J'avais trouvé ce script, à insérer avant la compilation : Cela fonctionnait très bien, mais xCode a changé, et les nouveaux projets ne range plus directement le numéro de Build dans le fichier Info.plist et cela ne fonctionne donc plus. J'ai donc cherché une nouvelle méthode, et la voici. Tout d'abord il faut changer l&