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">
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.