HWASan-Berichte

Wenn das HWASan-Tool einen Speicherfehler erkennt, wird der Prozess mit abort() beendet und wird ein Report an stderr und logcat gedruckt. Wie bei allen nativen Abstürzen unter Android können HWASan-Fehler unter /data/tombstones gefunden.

Im Vergleich zu regulären nativen Abstürzen enthält HWASan zusätzliche Informationen im Feld „Nachricht abbrechen“ weiter oben auf dem Grabstein. Unten sehen Sie ein Beispiel für einen Heap-basierten Absturz. Informationen zu Stackfehlern finden Sie im Hinweis unten.

Beispielbericht

*** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
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 …]

Dies ist einem AddressSanitizer-Bericht sehr ähnlich. Im Gegensatz dazu sind fast alle HWASan-Programmfehler „Tag-mismatch“, d.h. ein Speicherzugriff, bei dem ein Zeiger-Tag nicht mit dem entsprechenden Speicher-Tag übereinstimmen. Das könnte einer der folgenden sein:

  • Außerhalb des Zugriffsbereichs auf Stack oder Heap
  • Nach der Freischaltung auf Heap verwenden
  • Verwendung nach Rückgabe des Stacks

Abschnitte

Im Folgenden werden die einzelnen Abschnitte des HWASan-Berichts erläutert:

Zugriffsfehler

Enthält Informationen zum fehlerhaften Arbeitsspeicherzugriff, darunter:

  • Zugriffstyp ("READ" oder "WRITE")
  • Zugriffsgröße (wie viele Byte versucht wurden, auf zuzugreifen)
  • Thread-Nummer des Zugriffs
  • Zeiger- und Speicher-Tags (zur erweiterten Fehlerbehebung)

Auf den Stacktrace zugreifen

Stacktrace des fehlerhaften Arbeitsspeicherzugriffs. Im Abschnitt Symbolisierung erfahren Sie, wie Sie zu symbolisieren.

Ursache

Die mögliche Ursache für den schlechten Zugriff. Gibt es mehrere Kandidaten, sind absteigend nach Wahrscheinlichkeit sortiert. Überspringt die detaillierten Informationen zum mögliche Ursache zu ermitteln. Mit HWASan können die folgenden Ursachen diagnostiziert werden:

  • Use After Free
  • Stack-Tag-Abweichung: Dies kann ein Stack „use-after-return“, „use after-scope“ sein oder Außerhalb des gültigen Bereichs
  • Heap-Buffer-Overflow
  • Globaler Überlauf

Informationen zum Arbeitsspeicher

Beschreibt, was HWASan über den Speicher weiß, auf den zugegriffen wird, und kann abweichen basierend auf den Art des Fehlers.

Programmfehlertyp Ursache Berichtsformat
Tag stimmt nicht überein Use After Free 
<address> is located N bytes inside of M-byte region [<start>, <end>)
  freed by thread T0 here:
Heap-Buffer-Overflow Es kann sich auch um einen Unterlauf handeln. 
<address> is located N bytes to the right of M-byte region [<start>, <end>)
  allocated here:
Stack-Tag stimmt nicht überein In Stack-Berichten wird nicht zwischen Überlauf/Unterlauf und nach der Rückgabe zurück. In um die Stack-Zuordnung zu finden, die die Fehlerquelle ist, offline Symbolisierungsschritt ist erforderlich. Weitere Informationen zu Stack-Berichten weiter unten.
ungültig-kostenlos Use After Free Das ist ein doppelter Fehler. Wenn dies beim Herunterfahren eines Prozesses passiert, kann dies auf eine Verstoß gegen die Richtlinie zur Einwilligung der Nutzer in der EU: 
<address> is located N bytes inside of M-byte region [<start>, <end>)
  freed by thread T0 here:
kann die Adresse nicht beschreiben Entweder ein kostenloser Speicher (ohne Arbeitsspeicher, der zuvor noch nicht zugewiesen wurde) oder Double Free nachdem der zugeteilte Speicher aus dem kostenlosen Zwischenspeicher von HWASan entfernt wurde.
0x... ist ein HWAsan-Schattenspeicher. Das ist definitiv kostenlos, denn die App hat versucht, die eine wichtige Rolle spielt, für HWASan genutzt.

Deallocation-Stacktrace

Stacktrace, wo die Speicherfreigabe freigegeben wurde. Nur für die Nutzung im Anschluss an die kostenlose Nutzung präsentieren oder Bugs, die keine ungültig sind. Informationen zu Symbolisierungen finden Sie im Abschnitt „Symbolisierung“.

Zuordnungs-Stacktrace

Stacktrace, wo der Arbeitsspeicher zugewiesen wurde. Informationen zu Symbolisierungen finden Sie im Abschnitt „Symbolisierung“.

Erweiterte Fehlerbehebung Informationen

Der HWASan-Bericht bietet auch einige erweiterte Debugging-Informationen, (in dieser Reihenfolge):

  1. Die Liste der Threads im Prozess
  2. Die Liste der Threads im Prozess
  3. Der Wert der Speicher-Tags in der Nähe des fehlerhaften Arbeitsspeichers
  4. Der Dump der Register am Punkt des Arbeitsspeicherzugriffs

Speicher-Tag-Dump

Mit dem Tag-Arbeitsspeicher-Dump kann nach Arbeitsspeicherzuweisungen in der Nähe mit demselben Tag gesucht werden als Zeiger Tag. Diese könnten auf einen außerhalb des gültigen Bereichs befindlichen Zugriff mit einem großen Offset hinweisen. Ein Tag entspricht 16 Bytes der Erinnerung; Das Pointer-Tag sind die oberen 8 Bits der Adresse. Mit dem Tag-Arbeitsspeicher-Dump Tipps geben, für Das folgende Beispiel zeigt einen Pufferüberlauf nach rechts: 

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  ..  ..  ..  ..  ..  ..  ..  ..  ..  ..  ..  ..  ..  ..
Beachten Sie, dass links 6 × 16 = 96 Byte der „ad“-Tags, die mit dem Zeiger-Tag übereinstimmen, links ausgeführt werden.

Wenn die Größe einer Zuweisung kein Vielfaches von 16 ist, ist der Rest der Größe gespeichert als memory tag und das Tag wird als kurzes Tag Granule-Tag. Im Beispiel oben wird direkt nach der fett formatierten Zuordnung Anzeige, haben wir habe eine 5 × 16 + 4 = 84-Byte-Zuordnung von Tag 5c.

Ein Tag ohne Arbeitsspeicher (z. B. tags: ad/00 (ptr/mem)) steht normalerweise für einen „Stack-use-after-return“-Programmfehler.

Dump registrieren

Der Register-Dump in HWASan-Berichten entspricht der Anweisung, die die ungültig Arbeitsspeicher Zugriff haben. Darauf folgt ein weiterer Register-Dump vom regulären Android-Signal-Handler. – ignorieren Sie die die zweite. Sie wird erfasst, wenn HWASan „Abbruch()“ aufruft, und ist für Fehler beheben.

Symbolisierung

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

Zum Abrufen von Funktionsnamen und Zeilennummern in Stacktraces (und zum Abrufen von Variablennamen für Use-After-Scope) Bugs), ist ein Offline-Symbolisierungsschritt erforderlich.

Erstmalige Einrichtung: llvm-symbolizer installieren

Zur Symbolisierung muss auf Ihrem System llvm-symbolizer installiert sein, auf den über $PATH zugegriffen werden kann. Unter Debian können Sie installieren Sie es mit sudo apt install llvm.

Symboldateien abrufen

Für die Symbolisierung sind Binärdateien ohne Trennzeichen erforderlich, die Symbole enthalten. Wo Sie diese finden, hängt davon ab, zum Build-Typ:

Für lokale Builds finden Sie die Symboldateien hier: out/target/product/<product>/symbols/

Für AOSP-Builds (z.B., die von Flashstation geflasht wurden), gilt der Parameter Builds finden Sie unter Android CI. Wählen Sie im Bereich „Artefakte“ für die Entwicklung, wird eine ${PRODUCT}-symbols-${BUILDID}.zip-Datei erstellt.

Informationen zu internen Builds Ihrer Organisation finden Sie in der entsprechenden Dokumentation das Abrufen von Symboldateien.

Symbolisieren

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

Stack-Berichte verstehen

Für Fehler, die bei Stackvariablen auftreten, enthält der HWASan-Bericht folgende Details: 

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)
  [...]

Damit Stapelfehler besser verstanden werden können, verfolgt HWASan die Stapelframes in der Vergangenheit. Derzeit wandelt HWASan dies im Fehlerbericht nicht in für Menschen verständliche Inhalte um. erfordert einen zusätzlichen Symbolisierungsschritt.

Verstöße gegen die ODR

Einige von HWASan gemeldete Fehler nach der Verwendung können auch auf einen Verstoß gegen die One Definition Rule (ODR) hinweisen. Ein ODR-Verstoß tritt auf, wenn dieselbe Variable mehrmals im selben Programm definiert ist. Das bedeutet auch, dass die Variable mehrmals gelöscht wurde, was dazu führen kann, dass Use-After-Free-Fehler.

Nach der Symbolisierung wird bei ODR-Verstößen ein Use-After-Free-Prinzip mit __cxa_finalize angezeigt. sowohl im ungültigen Zugriffspaket als auch auf der Seite „Hier freigegeben“ Stacks. Die zuvor zugewiesenen hier“ Stapel enthält __dl__ZN6soinfo17call_constructorsEv und sollte an der Stelle in Ihrem Programm, an der die Variable weiter oben im Stack definiert wird.

Ein Grund für einen Verstoß gegen die ODR kann die Verwendung statischer Bibliotheken sein. Wenn eine statische Bibliothek, die eine globale C++-Definition definiert, mit mehreren gemeinsam genutzten Bibliotheken oder ausführbare Dateien, mehrere Definitionen desselben Symbols können am Ende unter derselben Adresse vorhanden sein Speicherplatz, was zu einem ODR-Fehler führt.

Fehlerbehebung

HWAddressSanitizer kann die Adresse nicht genauer beschreiben

Manchmal reicht der Speicherplatz für HWASan für Informationen über frühere Arbeitsspeicherzuweisungen aus. In diesem Fall wird der Bericht enthält nur einen Stacktrace für den sofortigen Arbeitsspeicherzugriff, gefolgt von einem Hinweis:

  HWAddressSanitizer can not describe address in more detail.

In einigen Fällen kann das Problem behoben werden, indem der Test mehrmals ausgeführt wird. Eine weitere Möglichkeit besteht darin, die Größe des Verlaufs. Dies kann weltweit in build/soong/cc/sanitize.go (suchen Sie nach hwasanGlobalOptions) oder in Ihrer Prozessumgebung (versuchen Sie adb shell echo $HWASAN_OPTIONS, um die aktuellen Einstellungen aufzurufen.

Dies kann auch passieren, wenn der Arbeitsspeicher, auf den zugegriffen wird, nicht zugeordnet oder von einem Nicht-HWASan-bewussten Speicher zugewiesen wurde. -Allocator. In diesem Fall ist das im Absturz-Header aufgeführte mem-Tag in der Regel 00. Wenn Sie Zugriff auf den gesamten Tombstone haben, kann es hilfreich sein, sich an das Dump von Arbeitsspeicherzuordnungen, um herauszufinden, zu welcher Zuordnung (falls vorhanden) die Adresse gehört.

Verschachtelter Fehler im selben Thread

Dies bedeutet, dass beim Erstellen des HWASan-Absturzberichts ein Fehler aufgetreten ist. Dies ist meist auf einen Fehler im HWASan-Laufzeit: Melden Sie den Fehler und Anweisungen zum Reproduzieren des Problems geben, falls möglich.