Aucune mémoire initialisée

La mémoire non initialisée en C et C++ est une cause courante de problèmes de fiabilité, les bugs de sécurité de la mémoire et les fuites d'informations. Pour éviter ces problèmes, Android initialise autant de mémoire que possible.

Aucune mémoire d'espace utilisateur initialisée

Depuis Android 12, la mémoire de la pile est zéro initialisée dans le code natif de toute la plate-forme (y compris JNI) et la mémoire du tas de mémoire est nulle. initialisé dans tous les processus natifs de la plate-forme (tels que netd) mais pas dans zygote ni dans les applications.

Les applications propriétaires et tierces créées avec le NDK sont fortement recommandé d'utiliser l'indicateur de compilation -ftrivial-auto-var-init=zero pour initialiser complètement la pile locale variables. Le compilateur optimise la mise à zéro inutile. Par exemple, lorsqu'une variable locale est explicitement initialisée (par exemple, la variable int x = 123; x n'est initialisée qu'une seule fois). Si le programme dispose d'un tampon de pile volumineux dans le développeur peut désactiver l'initialisation à l'aide d'un compilateur attribut:

__attribute__((__uninitialized__)) char buf[BUFSIZ];

Les applications peuvent également activer l'initialisation sans tas de mémoire à l'aide du Attribut de fichier manifeste android:nativeHeapZeroInitialized. L'initialisation de l'absence de segment de mémoire peut également être contrôlée au moment de l'exécution. par:

int mallopt(M_BIONIC_ZERO_INIT, level)

Où le niveau est 0 ou 1.

<ph type="x-smartling-placeholder">

Aucune mémoire de noyau initialisée

La pile et le tas de mémoire du noyau sont initialisés à zéro pour les noyaux GKI, ce qui est fortement recommandées par le CDD.

Pour l'initialisation de la pile, GKI utilise CONFIG_INIT_STACK_ALL_ZERO, ce qui entraîne la création de la noyau à l'aide de l'indicateur de compilation -ftrivial-auto-var-init=zero. Pour l'initialisation du tas de mémoire, GKI utilise CONFIG_INIT_ON_ALLOC_DEFAULT_ON, qui rend le tas de mémoire de toute la page, SLAB et SLUB sont initialisés à zéro lors de leur création. Cette option est de manière similaire à la transmission de init_on_alloc=1 en tant que noyau de démarrage rapide.

Rapports de bugs

Nos outils génèrent des rapports de bugs pertinents contenant des informations supplémentaires pour faciliter le débogage. Trace supplémentaire de la pile d'allocation et de désallocation de mieux comprendre le cycle de vie d'une allocation donnée et d'obtenir les bugs de sécurité de la mémoire causant la racine beaucoup plus rapidement.

<ph type="x-smartling-placeholder">
</ph> Exemple de rapport de bug généré
  par l&#39;outil de sécurité de la mémoire
Figure 1: Rapports de bugs générés par les outils de sécurité de la mémoire

Pendant le développement, les fournisseurs doivent surveiller la présence de bugs /data/tombstones et logcat pour les plantages natifs. Pour en savoir plus sur déboguer le code natif Android, consultez cette page pour en savoir plus.