Comprendre les rapports HWASan

Lorsque l'outil HWASan détecte un bug de mémoire, le processus s'arrête avec abort(), et un rapport est imprimé dans stderr et Logcat. Comme pour tous les plantages natifs sur Android, les erreurs HWASan peuvent être trouvé sous /data/tombstones.

Par rapport aux plantages natifs standards, HWASan affiche des informations supplémentaires dans le champ "Annuler le message" vers le haut de la pierre tombale. Consultez ci-dessous un exemple de plantage basé sur les tas de mémoire (pour les bugs de pile, consultez la remarque ci-dessous pour les sections spécifiques à la pile).

Exemple de rapport

*** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
Build fingerprint: 'google/flame_hwasan/flame:Tiramisu/MASTER/7956676:userdebug/dev-keys'
Revision: 'DVT1.0'
ABI: 'arm64'
Timestamp: 2019-04-24 01:13:22+0000
pid: 11154, tid: 11154, name: sensors@1.0-ser  >>> /vendor/bin/hw/android.hardware.sensors@1.0-service <<<
signal 6 (SIGABRT), code -1 (SI_QUEUE), fault addr --------
Abort message: '

[...]

[0x00433ae20040,0x00433ae20060) is a small unallocated heap chunk; size: 32 offset: 5








[ … regular crash dump follows …]

Ce rapport est très semblable à un rapport AddressSanitizer. Contrairement à ceux-ci, presque tous les bugs HWASan sont des "tag-mismatch", c'est-à-dire un accès à la mémoire où une balise de pointeur fonctionne. ne correspondent pas au tag de mémoire correspondant. Il peut s'agir de

  • accès hors limites sur la pile ou le tas de mémoire
  • utiliser après libération sur le tas de mémoire
  • à utiliser après le retour sur la pile

Sections

Vous trouverez ci-dessous une explication de chacune des sections du rapport HWASan:

Erreur d'accès

Contient des informations sur l'accès à la mémoire de mauvaise qualité, y compris:

  • Type d'accès ("LECTURE" ou "ÉCRITURE")
  • Taille de l'accès (nombre de tentatives d'accès)
  • Numéro de thread de l'accès
  • Pointeur et balises de mémoire (pour le débogage avancé)

Accéder à la trace de la pile

Trace de la pile de l'accès incorrect à la mémoire. Consultez la section sur la symbolisation pour décoder.

Cause

Cause potentielle du mauvais accès. S'il y a plusieurs candidats, sont classées par ordre de probabilité décroissante. Précise les informations détaillées sur le la cause potentielle. HWASan peut diagnostiquer les causes suivantes:

  • utilisation après sans frais
  • Non-concordance d'une balise de pile: il peut s'agir d'une utilisation de la pile après un retour, d'une utilisation après la portée, ou hors limites
  • Dépassement de la mémoire tampon du tas de mémoire
  • Global-overflow

Informations sur la mémoire

Décrit ce que HWASan sait de la mémoire en cours d'accès, et peut différer en fonction du type de bug.

Type de bug Cause Report Format (Format du rapport)
incohérence au niveau des balises utilisation après sans frais 
<address> is located N bytes inside of M-byte region [<start>, <end>)
  freed by thread T0 here:
Dépassement de la mémoire tampon du tas de mémoire Notez qu'il peut également s'agir d'un dépassement de capacité. 
<address> is located N bytes to the right of M-byte region [<start>, <end>)
  allocated here:
non-concordance des tags de pile Les rapports de pile ne font pas la différence entre les dépassements et dépassements de capacité les bugs d'utilisation après retour. Dans De plus, pour trouver l'allocation de pile qui est à l'origine de l'erreur, hors connexion l'étape de décodage est obligatoire. Consultez l'article Comprendre les rapports empilés. ci-dessous.
non valide utilisation après sans frais Il s'agit d'un double bug sans frais. Si cela se produit lors de l'arrêt d'un processus, cela peut indiquer Non-respect des règles ODR. 
<address> is located N bytes inside of M-byte region [<start>, <end>)
  freed by thread T0 here:
ne peut pas décrire l'adresse Il peut s'agir d'une classe "free" (libre de la mémoire n'ayant pas été allouée auparavant) ou double sans frais après l'éviction de la mémoire allouée du tampon libre de HWASan.
0x... est la mémoire fantôme HWAsan. Il s'agit d'une solution totalement totalement libre, car l'application essayait mémoire qui est internes à HWASan.

Trace de la pile de désallocation

Trace de la pile indiquant où la mémoire a été désaffectée. Disponible uniquement pour une utilisation après libération ou des bugs inoffensifs. Consultez la section sur la symbolisation pour en savoir plus sur la décodage.

Trace de la pile d'allocation

Trace de la pile indiquant l'emplacement où la mémoire a été allouée. Consultez la section sur la symbolisation pour en savoir plus sur la décodage.

Débogage avancé Informations

Le rapport HWASan contient également des informations de débogage avancées, y compris (dans l'ordre):

  1. La liste des threads du processus
  2. La liste des threads du processus
  3. La valeur des balises de mémoire proches de la mémoire défaillante
  4. Le vidage des registres au point d'accès à la mémoire

Vidage du tag de mémoire

Le vidage de la mémoire du tag peut être utilisé pour rechercher les allocations de mémoire à proximité avec la même balise. en tant que pointeur . Ceux-ci peuvent indiquer un accès hors limites avec un décalage important. Une balise correspond à 16 octets de mémoire, la balise de pointeur correspond aux 8 premiers bits de l’adresse. Le vidage de la mémoire du tag donner des indices, pour Voici un exemple de débordement de tampon vers la droite: 

tags: ad/5c (ptr/mem)
[...]
Memory tags around the buggy address (one tag corresponds to 16 bytes):
  0x006f33ae1ff0: 0e  0e  0e  57  20  20  20  20  20  2e  5e  5e  5e  5e  5e  b5
=>0x006f33ae2000: f6  f6  f6  f6  f6  4c  ad  ad  ad  ad  ad  ad [5c] 5c  5c  5c
  0x006f33ae2010: 5c  04  2e  2e  2e  2e  2e  2f  66  66  66  66  66  80  6a  6a
Tags for short granules around the buggy address (one tag corresponds to 16 bytes):
  0x006f33ae1ff0: ab  52  eb  ..  ..  ..  ..  ..  ..  ..  ..  ..  ..  ..  ..  ..
=>0x006f33ae2000: ..  ..  ..  ..  ..  ..  ..  ..  ..  ..  ..  .. [..] ..  ..  ..
  0x006f33ae2010: ..  5c  ..  ..  ..  ..  ..  ..  ..  ..  ..  ..  ..  ..  ..  ..
 Notez que l'exécution de 6 × 16 = 96 octets de tags "publicitaires" à gauche correspondant au tag de pointeur.

Si la taille d'une allocation n'est pas un multiple de 16, le reste de la taille sera stockés en tant que tag "memory" et le tag sera stocké sous forme de fichier court granule tag. Dans l'exemple ci-dessus, juste après l'allocation taguée nous CANNOT TRANSLATE × 16 + 4 = Attribution de la balise 5c à 84 octets

Une balise sans mémoire (par exemple, tags: ad/00 (ptr/mem)) indique généralement Stack-use-after-return bug.

Enregistrer le fichier de dump

Le registre de dump dans les rapports HWASan correspond à l'instruction réelle qui a exécuté la non valide mémoire y accéder. Elle est suivie d'un autre vidage de registre du gestionnaire de signaux Android standard. - ignorer les le second, il est pris lorsque HWASan a appelé "abandon()" et n'est pas pertinent pour le bug.

Symbolisation

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

Pour obtenir les noms de fonctions et les numéros de ligne dans les traces de la pile (et obtenir les noms des variables à utiliser après la portée de bugs), une étape de décodage hors connexion est nécessaire.

Première configuration: installer llvm-symbolizer

Pour symboliser, votre système doit avoir installé llvm-symbolizer et être accessible à partir de $PATH. Sur Debian, vous pouvez installez-la avec sudo apt install llvm.

Obtenir des fichiers de symboles

Pour la décodage, nous avons besoin de binaires complets contenant des symboles. L'emplacement de ces informations dépend sur le type de compilation:

Pour les builds locaux, les fichiers de symboles se trouvent dans out/target/product/<product>/symbols/

Pour les builds AOSP (par exemple, avec Flashstation), le builds sont disponibles sur Android CI. Dans la section "Artefacts", pour le créer, il y a un fichier ${PRODUCT}-symbols-${BUILDID}.zip.

Pour les builds internes de votre organisation, consultez la documentation de votre organisation pour obtenir de l'aide. obtenir des fichiers de symboles.

Symboliser

hwasan_symbolize –-symbols <DECOMPRESSED_DIR>/out/target/product/*/symbols < crash
 <ph type="x-smartling-placeholder">

Comprendre les rapports de la pile

Pour les bugs qui se produisent avec des variables de pile, le rapport HWASan contiendra des informations telles que celles-ci: 

Cause: stack tag-mismatch
Address 0x007d4d251e80 is located in stack of thread T64
Thread: T64 0x0074000b2000 stack: [0x007d4d14c000,0x007d4d255cb0) sz: 1088688 tls: [0x007d4d255fc0,0x007d4d259000)
Previously allocated frames:
  record_addr:0x7df7300c98 record:0x51ef007df3f70fb0  (/apex/com.android.art/lib64/libart.so+0x570fb0)
  record_addr:0x7df7300c90 record:0x5200007df3cdab74  (/apex/com.android.art/lib64/libart.so+0x2dab74)
  [...]

Pour que les bugs de pile soient bien compris, HWASan effectue le suivi des blocs de pile survenus par le passé. Actuellement, HWASan ne le transforme pas en contenu compréhensible par l'humain dans le rapport de bug. nécessite une étape de décodage supplémentaire.

Non-respect des règles ODR

Certains bugs d'utilisation après libération signalés par HWASan peuvent également indiquer un non-respect de la règle de définition unique (ODR, One Definition Rule). Un cas de non-respect des règles ODR se produit lorsqu'une même variable est définie plusieurs fois dans le même programme. Cela signifie également que la variable est détruite plusieurs fois, ce qui peut entraîner le « use-after-free ».

Après la décodage, les cas de non-respect des règles ODR indiquent une utilisation après libération avec __cxa_finalize, à la fois sur la pile d'accès non valide et sur les données "libérés ici" pile. La valeur "précédemment allouée ici" la pile contient __dl__ZN6soinfo17call_constructorsEv et doit point à l'emplacement de votre programme qui définit la variable plus haut dans la pile.

L'ODR peut être enfreint en raison de l'utilisation de bibliothèques statiques. Si une bibliothèque statique qui définit un élément global C++ est liée à plusieurs bibliothèques partagées ou exécutables, plusieurs définitions du même symbole peuvent finir par exister à la même adresse ce qui génère une erreur ODR.

Dépannage

HWAddressSanitizer ne peut pas décrire l'adresse plus en détail.

HWASan peut parfois manquer d'espace pour obtenir des informations sur les allocations de mémoire précédentes. Dans ce cas, le rapport contient une seule trace de pile pour l'accès immédiat à la mémoire, suivie d'une remarque:

  HWAddressSanitizer can not describe address in more detail.

Dans certains cas, vous pouvez résoudre ce problème en exécutant le test plusieurs fois. Vous pouvez aussi augmenter la valeur de HWASan la taille de l'historique. Cela peut se faire à l'échelle mondiale build/soong/cc/sanitize.go (recherchez hwasanGlobalOptions) ou dans votre environnement de traitement (essayez adb shell echo $HWASAN_OPTIONS pour afficher les paramètres actuels).

Cela peut également se produire si la mémoire consultée n'est pas mappée ou allouée par un utilisateur non compatible avec HWASan. d'un outil d'allocation. Dans ce cas, la balise mem figurant dans l'en-tête du plantage est généralement 00 Si vous avez accès à l'intégralité de la pierre tombale, il peut être utile de consulter le vider les mappages de mémoire pour savoir à quelle mise en correspondance (le cas échéant) appartient l'adresse.

Bug imbriqué dans le même fil de discussion

Cela signifie qu'un bug s'est produit lors de la génération du rapport d'erreur HWASan. Cela est généralement dû à un bug dans de l'environnement d'exécution HWASan, veuillez signaler un bug et Si possible, indiquez comment reproduire le problème.