Dieses Problem kann nicht reproduziert werden. @nikolowry kannst du vielleicht auch testen?

Kann dieses Problem auch nicht reproduzieren. Video wurde bei mir gut abgespielt.

@subi54 danke fürs testen.

@proteriax irgendein Hinweis in Ihrem ADB-Logcat? Vielleicht verfügt Ihr Android-Betriebssystem nicht über eine Codec-Decodierungsfunktion?

Das erlebe ich auch, zum Beispiel auf Twitter. Die ersten paar Frames werden abgespielt (mit Ton), dann stürzt der Player ab. Auf Chrome 79.0.3945.93 werden dieselben Videos ohne Probleme abgespielt. Ich verwende ein Pixel 2 XL mit Android 10 (Dezember). Werde versuchen, einen Logcat zu ziehen.

Ich kann das Problem auf YouTube reproduzieren.

Wie @kkkrist sagte,

Die ersten paar Frames werden abgespielt (mit Ton), dann stürzt der Player ab.
die gleichen Videos werden ohne Probleme abgespielt.

Das beschreibt das Problem genau. Ziehe jetzt einen Logcat, ein paar Augenblicke bitte...

@kkkrist @icejr sicher, nimm dir Zeit. Ich hätte es vielleicht auch manchmal reproduzieren können, aber über längere Zeiträume der Wiedergabe.

Ich denke, das Problem könnte auch v78 betroffen haben.

Ich habe dieses Problem auch bei den meisten Videos. Ich verstehe tatsächlich, dass Bronite den Dialog ständig stoppt. Die Schaltfläche App schließen tötet Bromite jedoch nicht. Bei der letzten Veröffentlichung ist es nicht passiert. Und die Sites funktionieren in Chrome stabil.

Dies ist von einem gerooteten, aber ansonsten auf Lager befindlichen Pixel 3 XL mit Android 10 und dem Dezember-Patch.

[logcat_12-21-2019_16-10-15.zip]

Hier sind einige Protokolle:

[ENTFERNT]

Dieses Problem war in v78 auf meiner Seite nicht vorhanden, hätte ich sicherlich bemerkt.

Der in Ihrem Logcat gefundene Absturz:

[12-21 22:57:27.025 11775:11775 F/DEBUG]*** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
[12-21 22:57:27.026 11775:11775 F/DEBUG]Build fingerprint: 'google/taimen/taimen:10/QQ1A.191205.008/5974827:user/release-keys'
[12-21 22:57:27.026 11775:11775 F/DEBUG]Revision: 'rev_10'
[12-21 22:57:27.026 11775:11775 F/DEBUG]ABI: 'arm64'
[12-21 22:57:27.027 11775:11775 F/DEBUG]Timestamp: 2019-12-21 22:57:27+0100
[12-21 22:57:27.027 11775:11775 F/DEBUG]pid: 11707, tid: 11760, name: ImageReader-1x1  >>> org.bromite.bromite:privileged_process0 <<<
[12-21 22:57:27.027 11775:11775 F/DEBUG]uid: 10292
[12-21 22:57:27.027 11775:11775 F/DEBUG]signal 6 (SIGABRT), code -6 (SI_TKILL), fault addr --------
[12-21 22:57:27.027 11775:11775 F/DEBUG]    x0  0000000000000000  x1  0000000000002df0  x2  0000000000000006  x3  00000070ecefe980
[12-21 22:57:27.027 11775:11775 F/DEBUG]    x4  802322110c49122b  x5  802322110c49122b  x6  802322110c49122b  x7  42606863644c3fff
[12-21 22:57:27.027 11775:11775 F/DEBUG]    x8  00000000000000f0  x9  000000717e9384e0  x10 0000000000000000  x11 0000000000000001
[12-21 22:57:27.027 11775:11775 F/DEBUG]    x12 000000000001ac70  x13 0000000000000002  x14 0000000000000000  x15 0000007180af3020
[12-21 22:57:27.027 11775:11775 F/DEBUG]    x16 000000717ea048c0  x17 000000717e9e2060  x18 00000070a06ca000  x19 00000000000000ac
[12-21 22:57:27.027 11775:11775 F/DEBUG]    x20 0000000000002dbb  x21 00000000000000b2  x22 0000000000002df0  x23 00000000ffffffff
[12-21 22:57:27.027 11775:11775 F/DEBUG]    x24 00000070eceff020  x25 00000070ecefed50  x26 0000007180860138  x27 00000000000fd000
[12-21 22:57:27.027 11775:11775 F/DEBUG]    x28 0000007089252000  x29 00000070ecefea30
[12-21 22:57:27.027 11775:11775 F/DEBUG]    sp  00000070ecefe960  lr  000000717e996170  pc  000000717e9961a0
[12-21 22:57:27.040 11775:11775 F/DEBUG]
backtrace:
[12-21 22:57:27.040 11775:11775 F/DEBUG]      #00 pc 00000000000821a0  /apex/com.android.runtime/lib64/bionic/libc.so (abort+176) (BuildId: b58d049709674405423a8d8de1a37f56)
[12-21 22:57:27.041 11775:11775 F/DEBUG]      #01 pc 00000000000186d4  /system/lib64/libmediandk.so (__cfi_check_fail+24) (BuildId: 070ca91395586cffc473ba31eee93910)
[12-21 22:57:27.041 11775:11775 F/DEBUG]      #02 pc 000000000001ade4  /system/lib64/libmediandk.so (__cfi_check+7652) (BuildId: 070ca91395586cffc473ba31eee93910)
[12-21 22:57:27.041 11775:11775 F/DEBUG]      #03 pc 0000000000046ef4  /apex/com.android.runtime/bin/linker64 (__dl__ZN15CFIShadowWriter7CfiFailEmPvS0_S0_+124) (BuildId: 52561db5295b9b5f246e5c95d06a6b3c)
[12-21 22:57:27.041 11775:11775 F/DEBUG]      #04 pc 0000000000001160  /apex/com.android.runtime/lib64/bionic/libdl.so (__cfi_slowpath+64) (BuildId: 12e0c86c59cc11545d28655d0e51c65a)
[12-21 22:57:27.041 11775:11775 F/DEBUG]      #05 pc 0000000000029f2c  /system/lib64/libmediandk.so (AImageReader::CallbackHandler::onMessageReceived(android::sp<android::AMessage> const&)+404) (BuildId: 070ca91395586cffc473ba31eee93910)
[12-21 22:57:27.041 11775:11775 F/DEBUG]      #06 pc 0000000000016960  /system/lib64/libstagefright_foundation.so (android::AHandler::deliverMessage(android::sp<android::AMessage> const&)+48) (BuildId: c58afc2199618f4e88ce8d6482bcc221)
[12-21 22:57:27.041 11775:11775 F/DEBUG]      #07 pc 000000000001a4a4  /system/lib64/libstagefright_foundation.so (android::AMessage::deliver()+100) (BuildId: c58afc2199618f4e88ce8d6482bcc221)
[12-21 22:57:27.041 11775:11775 F/DEBUG]      #08 pc 00000000000173cc  /system/lib64/libstagefright_foundation.so (android::ALooper::loop()+564) (BuildId: c58afc2199618f4e88ce8d6482bcc221)
[12-21 22:57:27.041 11775:11775 F/DEBUG]      #09 pc 00000000000137c0  /system/lib64/libutils.so (android::Thread::_threadLoop(void*)+312) (BuildId: 1a9baf080e66cccc6106194a0c4147f8)
[12-21 22:57:27.041 11775:11775 F/DEBUG]      #10 pc 00000000000c1794  /system/lib64/libandroid_runtime.so (android::AndroidRuntime::javaThreadShell(void*)+140) (BuildId: de057b63e21f6c0880ad2d2827b8a843)
[12-21 22:57:27.041 11775:11775 F/DEBUG]      #11 pc 00000000000e2364  /apex/com.android.runtime/lib64/bionic/libc.so (__pthread_start(void*)+36) (BuildId: b58d049709674405423a8d8de1a37f56)
[12-21 22:57:27.041 11775:11775 F/DEBUG]      #12 pc 0000000000083d98  /apex/com.android.runtime/lib64/bionic/libc.so (__start_thread+64) (BuildId: b58d049709674405423a8d8de1a37f56)

Es ist ein Lampenfieber/ImageReader-Absturz, und ich denke, es wurde bereits im Upstream gemeldet: https://bugs.chromium.org/p/chromium/issues/detail?id=977583

Lässt sich der Fehler mit entsprechender Chromium-Version reproduzieren?

Nein

@proteriax der Fehler lässt sich höchstwahrscheinlich mit Chromium reproduzieren, mit der entsprechenden Version konnte man nicht testen, da diese noch nicht freigegeben war/ist.

Es gibt bereits einen Patch in Bromite , um dem fehlerhaften AImageReader in Android 10 entgegenzuwirken, ich werde in der nächsten Version den zusätzlichen Workaround hinzufügen, der im Upstream-Problem angegeben ist; Bitte folgen Sie dem Upstream-Problem für die richtige Lösung.

Danke, dass Sie sich das angeschaut haben! Die oben erwähnte Chrome-Version, die Videos problemlos abspielt, ist tatsächlich 32-Bit (vorinstalliert und wurde über den Play Store aktualisiert), die von mir verwendete Bromite-Version ist 64-Bit.

@kkkrist wir verwenden Chromium, um zu überprüfen, ob Fehler wie diese vom Upstream oder von Bromite-Patches stammen, leider ist die zur aktuellen Bromite-Version passende Chromium-Version derzeit nicht verfügbar, wird aber in den nächsten Tagen verfügbar sein.

Wenn der Upstream die 64-Bit-Version nicht testet/veröffentlicht/wartet, müssen wir sie möglicherweise auch fallen lassen, obwohl es einige Vorteile bei der Verwendung gibt.

@csagan5 Danke. Mir ist nicht aufgefallen, dass die neueste Chromium-Version nicht übereinstimmt.

Dies geschieht immer noch am 79.0.3945.100. Bei mir öffne ich einfach einen YouTube-Link, manchmal läuft er 1-2 Sekunden, aktualisiert dann die Seite und spielt weitere 1-2 Sekunden, dann spielt er überhaupt nicht mehr.

Manchmal habe ich Glück und nach dem ersten Absturz lädt es das Video einwandfrei.

@tiagossa1 @proteriax @kkkrist @luisnogueira @godwintgn kannst du bitte mit der entsprechenden Chromium-Version 79.0.3945.100 testen?

https://www.bromit.org/chromium

Ja, es stürzt immer noch bei Twitter-Videos mit der 64-Bit-Version ab, während 32-Bit funktioniert. Gleiches mit Chrom 79.0.3945.100.

@kkkrist danke fürs testen. Da dies bei der entsprechenden Chromium-Version der Fall ist, können Sie dies am besten beheben, indem Sie im Upstream nachfragen (Bromite muss nicht erwähnt werden, der Chromium Issue Tracker befasst sich mit Chromium).

Die in https://bugs.chromium.org/p/chromium/issues/detail?id=977583 gemeldeten Fixes waren nicht wirksam, da sie bereits für die aktuelle Version vorhanden sind.

Ich habe gelesen, dass #disable-accelerated-video-decode dieses Problem auf arm64 mildern kann.

Ich wollte diesem Problem nur etwas mehr Kontext hinzufügen, ich kann es nicht replizieren, aber ich glaube, das liegt an Android 9 (Lineageos 16 mit MicroG) - also scheint dies auf Android 10 isoliert zu sein.

@csagan5 Das behebt das Problem. Anscheinend gibt es keine Zwangsschließung, die die beschleunigte Videodecodierung deaktiviert. Es funktioniert gut.

@nikolowry das Problem kann auf Android 9 ohne Bromites Patch repliziert werden; für Android 10 ist der Patch stattdessen wirkungslos.

Es scheint ein Fehler in Android Stagefright selbst zu sein, also müssen wir darauf warten.

Gleiches Problem bei *107 neueste Version.....

Ich habe gelesen, dass #disable-accelerated-video-decode dieses Problem auf arm64 mildern kann.

Kann bestätigen, dass dies das Problem in Android 10 (Sicherheitspatch vom Dezember) behebt.
Gerät - Oneplus 5T

Seit der neuesten Version 79.0.3945.111 die Videodekodierungsbeschleunigung auf Android 10+ und arm64 automatisch deaktiviert; Kann jemand bitte bestätigen, dass es keine Abstürze gibt, auch nachdem #disable-accelerated-video-decode auf Standard gesetzt wurde?

Jetzt keine Abstürze, aber ich kann keine Videos auf Facebook abspielen. Nach dem Klicken auf Play ist es schwarz. Ich habe die Option aktiviert und deaktiviert

@csagan5
Ich verwende Android 10 jetzt seit etwa 2 Monaten und habe in den drei Wochen, in denen ich v79 verwende, weder auf YouTube noch auf Facebook irgendwelche Abstürze mit Bromite für ARMv8 erlebt. Bei YouTube habe ich anscheinend keine Probleme beim Abspielen von 4K-Videos.

Ich verwende jedoch ein Gerät mit einem Huawei Kirin 980-Chipsatz, bei dem während des Updates auf Android 10 auch Mali-Treiber auf 18.0.01rel0 aktualisiert wurden. Es ist möglich, dass dies ein nur bei Qualcomm-Geräten auftretendes Problem ist.

Bearbeiten: Ich wäre gespannt, ob auch diejenigen mit Exynos-Geräten unter Android 10 kommentieren können, da sowohl Exynos als auch Kirin Mali-GPUs verwenden

Auch der kürzlich mit 79.0.3945.111 veröffentlichte Patch hat es unmöglich gemacht, die hardwarebeschleunigte Videodecodierung auf Android 10, 64-Bit-Builds wieder zu aktivieren. Wäre toll, wenn es geändert werden könnte, damit wir es wieder aktivieren könnten, wenn wir keine Abstürze haben.

Ich wäre gespannt, ob auch diejenigen mit Exynos-Geräten unter Android 10 kommentieren können, da sowohl Exynos als auch Kirin Mali-GPUs verwenden

@aluo-x das ist eine interessante Theorie, es wäre schön, sie zu überprüfen.

Der kürzlich mit 79.0.3945.111 veröffentlichte Patch hat es unmöglich gemacht, die hardwarebeschleunigte Videodecodierung auf Android 10, 64-Bit-Builds wieder zu aktivieren.

Das ist richtig, da ich meine Begründung auf zwei Tatsachen gestützt habe:

• Upstream wird das Problem schließlich beheben, und dann kann der Patch entfernt werden
• Es gibt keine Android 10 arm64-Geräte, die von dem Absturz nicht betroffen sind, da es sich um einen Fehler in der Android-Laufzeit handelt

Anscheinend lag ich bei (2) falsch? Ich würde gerne ein neues Flag dafür erstellen, aber zuerst: Können wir überprüfen, ob die Hardwarebeschleunigung auf Android 10 arm64-Geräten mit 79.0.3945.111 deaktiviert ist?

@aluo-x könnten Sie auch den Upstream nach der Korrelation mit dem GPU-Typ fragen? Ich gehe immer davon aus, dass es 100 weitere Benutzer/Entwickler im Upstream gibt, die bestätigen/verweigern können

Ich habe auf Android 10 die neueste Version von 3 Stunden Arm installiert und Videos funktionieren ... Werde die Arm64-Version nicht testen :(

@l-easwar-akiyama @tiagossa1 @kkkrist @proteriax können Sie bitte überprüfen, dass unter Android 10 mit arm64 das Ändern des Wertes des #disable-accelerated-video-decode Flags nicht zu einem Absturz mit 79.0.3945.111 oder höher führt?

Ich habe gerade einige Tests auf meinem Pixel 2 XL (Android 10, Januar-Patch) mit Twitter-Videos und Bromite 64-Bit durchgeführt.

• 79.0.3945.107 64-Bit-Abstürze mit aktivierter hardwarebeschleunigter Videodecodierung, stürzt nicht ab, wenn sie deaktiviert ist
• 79.0.3945.111 64-Bit stürzt überhaupt nicht ab, egal ob die hardwarebeschleunigte Videodecodierung aktiviert oder deaktiviert ist
• 79.0.3945.123 64-Bit stürzt überhaupt nicht ab, egal ob die hardwarebeschleunigte Videodecodierung aktiviert oder deaktiviert ist

Macht das Sinn? Macht das Flag "#disable-accelerated-video-decode" in Version 79.0.3945.111 und höher überhaupt etwas?

Macht das Sinn? Macht das Flag "#disable-accelerated-video-decode" in Version 79.0.3945.111 und höher überhaupt etwas?

@kkkrist danke fürs testen; das ist richtig, das Flag ist seit 79.0.3945.111 unwirksam, aber nur für Geräte mit Android 10 und der arm64-Version. Es gibt sozusagen eine harte Überschreibung, die so lange beibehalten wird, bis der Upstream-Bug https://bugs.chromium.org/p/chromium/issues/detail?id=977583 geschlossen wird.

@aluo-x Ich denke, es ist ein guter Kompromiss, das Flag ausgeschaltet zu lassen, bis der Upstream das Problem behebt. jemand könnte ihnen bei der Aktualisierung der GPU-Blacklist helfen, indem er bei Bedarf bestimmte Modelle hinzufügt.

Ich war tatsächlich in der Lage, die HW-Beschleunigung auf Sargo zum Laufen zu bringen und kann Abstürze nicht mehr reproduzieren.

Untersuche noch, was das eigentliche Problem ist.

@renlord Wie in ://gpu zeigt, ist die HW-Beschleunigung aktiviert?

@aluo-x

Schauen Sie sich diese an:

https://github.com/GrapheneOS/Vanadium/pull/52
https://github.com/GrapheneOS/Vanadium/pull/53

@renlord können Sie https://github.com/bromite/bromite/issues/467 reproduzieren

Wie bei den chrome://gpu Ausgaben, danke. Ich sehe, der Unterschied ist:

--- crashing.txt    2020-01-17 00:27:37.885246883 +0100
+++ fixed.txt   2020-01-17 00:27:55.605247074 +0100
@@ -75,16 +75,16 @@
 Raster is using a single thread.
 Disabled Features: multiple_raster_threads
 Version Information
-Data exported  2020-01-15T03:06:27.187Z
-Chrome version Chrome/79.0.3945.93
+Data exported  2020-01-15T03:07:46.881Z
+Chrome version Chrome/79.0.3945.116
 Operating system   Android 10
-Software rendering list URL    https://chromium.googlesource.com/chromium/src/+/5cacf84ee348e7ccedc2330d2520f9f342b3cfec/gpu/config/software_rendering_list.json
-Driver bug list URL    https://chromium.googlesource.com/chromium/src/+/5cacf84ee348e7ccedc2330d2520f9f342b3cfec/gpu/config/gpu_driver_bug_list.json
+Software rendering list URL    https://chromium.googlesource.com/chromium/src/+/64953db9f4468d309c976ee1823310d82c7ca6af/gpu/config/software_rendering_list.json
+Driver bug list URL    https://chromium.googlesource.com/chromium/src/+/64953db9f4468d309c976ee1823310d82c7ca6af/gpu/config/gpu_driver_bug_list.json
 ANGLE commit id    48aa52f7305a
-2D graphics backend    Skia/79 64f0af0f6548f7b8c45e7e3b2630e34deb04c1aa
+2D graphics backend    Skia/79 104d6dd34927d32b92c5f5b2a671b49fbe079080
 Command Line   --use-mobile-user-agent --top-controls-show-threshold=0.5 --top-controls-hide-threshold=0.5 --use-mobile-user-agent --enable-viewport --validate-input-event-stream --enable-longpress-drag-selection --touch-selection-strategy=direction --main-frame-resizes-are-orientation-changes --disable-composited-antialiasing --enable-dom-distiller --flag-switches-begin --flag-switches-end
 Driver Information
-Initialization time    189
+Initialization time    156
 In-process GPU false
 Passthrough Command Decoder    false
 Sandboxed  false

Wenn wir uns https://github.com/chromium/chromium/compare/5cacf84ee348e7ccedc2330d2520f9f342b3cfec...64953db9f4468d309c976ee1823310d82c7ca6af ansehen, gibt es keine Unterschiede für software_rendering_list.json und gpu_driver_bug_list.json und auch der Skia ist inkonsequent.

Der Vergleich der beiden Chromium-Tags gibt einen Hinweis: https://github.com/chromium/chromium/compare/79.0.3945.93...79.0.3945.116

Es gibt einen Bugfix für https://bugs.chromium.org/p/chromium/issues/detail?id=1027766 durch Commit https://github.com/chromium/chromium/commit/25607156d15800712a7056e43cd343049ef1af1a

Ich werde in Bromite die Harddisable für die Hardwarebeschleunigung entfernen. @renlord es ist mir jedoch nicht klar, ob der Workaround von https://bugs.chromium.org/p/chromium/issues/detail?id=977583 noch notwendig ist, da dieser einen größeren Einfluss hat/hatte (nicht nur Android10 /arm64).

Zum Glück können wir das mit den entsprechenden Chromium- Builds testen, die keine solchen Patches haben.

Können betroffene Benutzer hier (ohne arm64) bitte überprüfen, ob der neueste Chromium-Build noch von dem Absturzfehler betroffen ist?

Dieses Problem trat nach dem letzten Update wieder auf.

@proteriax das #disable-accelerated-video-decode wurde entfernt, da der Absturz nur bestimmte Hardware wie Ihre betrifft. Sie können das Flag manuell setzen (und daran denken, es zu entfernen, sobald der Upstream den Fehler behebt, falls überhaupt), oder zur arm Version wechseln (wobei alle Daten verloren gehen).

@renlord Das Entfernen des habe ich in

Mit Release 80 stürzen sowohl GitHub.com/bromite/bromite als auch GitHub.com/bromite/chromium bei der Videowiedergabe auf einem malischen arm64-Gerät ab.

@aluo-x Ich gehe davon aus, dass in beiden Fällen das Videodecodierungs-Flag (oder ein anderes verwandtes) unverändert ist?

Das ist richtig. Beides sind Neuinstallationen. Das Deaktivieren der Hardware-Videodecodierung "behebt" es. Als Referenz funktioniert der 32-Bit-Chrom-Build aus den offiziellen Quellen. Habe die 32-Bit-Bromite-Builds nicht getestet.

Ich denke, im Moment sollte nichts getan werden, es funktioniert möglicherweise immer noch für bestimmte Hardwarekonfigurationen und hoffentlich wissen die meisten Bromite-Benutzer über chrome:flags Bescheid

Bearbeiten: Ich habe auf das neueste M79-Bromit zurückgesetzt und die Videodecodierung funktioniert mit Hardwarebeschleunigung auf einem ARM64-Build.

Ich habe auf das neueste M79-Bromit zurückgesetzt und die Videodecodierung funktioniert mit Hardwarebeschleunigung auf einem ARM64-Build.

@aluo-x danke für deine Tests; ist dies bekannt, aber angeblich aufgrund unterschiedlicher Android-APIs, die von v79 verwendet werden?

Also heute gründlicher getestet, mit aktivierter Hardware-Videodecodierung (verifiziert in chrome://gpu):
M79 neuestes 32bit Bromit: kein Absturz
M79 neuestes 64bit Bromit: kein Absturz
M80 neueste 32bit Chrom (offiziell): kein Absturz
M80 neuestes 32bit Bromit: kein Absturz
M80 neuestes 64bit Chrom (Brom): Absturz
M80 neuestes 64bit Bromit: Absturz
Dies ist auf der Mali-GPU mit Android 10

@aluo-x Wenn wir herausfinden könnten, welche Änderungen zwischen M79 und M80 speziell für die hw-beschleunigte Videodecodierung vorgenommen wurden, könnten wir einen Fix versuchen. Aber ich fürchte, der Upstream ist für diese Aufgabe viel besser gerüstet.

Laut dem letzten Kommentar zum Upstream-Problem werden sie möglicherweise nach einem Fix in M81 gesucht.

Nur mein 2¢: Bis Chrome offiziell 64-Bit-Builds ausliefert, besteht eine hohe Wahrscheinlichkeit für diese Art von Upstream-Problem. Es könnte für einen Bromite klug sein, den 32-Bit-Build zu empfehlen. Und erstellen Sie ein separates F-Droid-Repository, da F-Droid versucht, Sie auf den 64-Bit-Build zu "aktualisieren".

Streng genommen gibt es also einen Fix für Chrome M80.

Ich denke jedoch, dass es vernünftiger wäre, dies im Upstream zu beheben und dies NICHT in Bromite zu patchen. Es ist einfach nicht realistisch, dass @csagan5 diese Brüche, die letztendlich repariert .

Streng genommen gibt es also einen Fix für Chrome M80.

@aluo-x dieser Fix ist bereits in Bromite vorhanden, siehe https://github.com/bromite/bromite/blob/80.0.3987.78/build/patches/Revert-Merge-to-M78-Enable-AImageReader-by-default .patch

Es reicht offenbar nicht aus.

bis Chrome offiziell 64-Bit-Builds ausliefert, besteht eine hohe Wahrscheinlichkeit für diese Art von Upstream-Problem. Es könnte für einen Bromite klug sein, den 32-Bit-Build zu empfehlen. Und erstellen Sie ein separates F-Droid-Repository, da F-Droid versucht, Sie auf den 64-Bit-Build zu "aktualisieren".

@ben-page Das F-Droid-Repository ist das eigene von Bromite, nicht das von F-Droid, sodass es nach Bedarf geändert werden kann. Es ist wahr, dass 64-Bit-Builds offiziell vom Upstream nicht unterstützt werden (und daher nicht getestet und beschädigt werden), aber sie haben bis jetzt funktioniert, also gibt es viele Benutzer, die dies installiert haben.

Ich befürchte, dass der Vorschlag, nur die 32-Bit-Version vorzuschlagen, die Benutzer der 64-Bit-Version zwingen würde, die Daten zu löschen, ist das richtig?

Eine andere Vorgehensweise wäre, den entsprechenden Android-Fehler zu finden und zu prüfen, ob es sich um einen Sicherheitsfehler handelt oder nicht; normalerweise werden Sicherheitsfehler schneller behoben. Siehe zum Beispiel https://github.com/GrapheneOS/platform_frameworks_av/commit/10af999ca8a27cd7ad6f82fed7139f2713939f4c von @thestinger

@nikolowry Wenn Sie Zeit haben, können Sie versuchen, M80 Chromium oder Bromite für arm64 mit is_cfi=false , nur für den Fall, dass es um den Absturz herum funktioniert (sollte nicht der Fall sein).

Ich befürchte, dass der Vorschlag, nur die 32-Bit-Version vorzuschlagen, die Benutzer der 64-Bit-Version zwingen würde, die Daten zu löschen, ist das richtig?

Mit Titanium Backup (Pro) auf einem gerooteten Gerät ist es möglich, nur den Datenteil des App-Backups wiederherzustellen, nachdem von 64 Bit auf 32 Bit und umgekehrt gewechselt wurde. So habe ich meine Tests gemacht.

@csagan5 Ich könnte es diese Woche

Ich habe jedoch einige GPU-bezogene Flags gesetzt, die sich von den Standardeinstellungen unterscheiden. Sie sind:

• #ignore-gpu-blacklist : Aktiviert
• #disable-webgl : Deaktiviert
• #enable-gpu-rasterization : Aktiviert
• #enable-oop-rasterization : Aktiviert
• #enable-zero-copy : Aktiviert

Hier ist der Bericht und ein Screenshot von chrome://gpu :

Data exported | 2020-02-12T15:22:50.167Z
-- | --
Chrome version | Chrome/79.0.3945.136
Operating system | Android 9
Software rendering list URL | https://chromium.9oo91esource.qjz9zk/chromium/src/+/cb5aa81cb0a3a2c674b93bc7ffb34a86cd3b4802/gpu/config/software_rendering_list.json
Driver bug list URL | https://chromium.9oo91esource.qjz9zk/chromium/src/+/cb5aa81cb0a3a2c674b93bc7ffb34a86cd3b4802/gpu/config/gpu_driver_bug_list.json
ANGLE commit id | 362168eb695d
2D graphics backend | Skia/80 97c9a95908bc8c7a6794259b35f366a3291e2d0f
Command Line | --use-mobile-user-agent --top-controls-show-threshold=0.5 --top-controls-hide-threshold=0.5 --use-mobile-user-agent --enable-viewport --validate-input-event-stream --enable-longpress-drag-selection --touch-selection-strategy=direction --main-frame-resizes-are-orientation-changes --disable-composited-antialiasing --enable-dom-distiller --flag-switches-begin --disable-webgl --enable-gpu-rasterization --enable-oop-rasterization --enable-zero-copy --ignore-gpu-blacklist --max-connections-per-host=15 --enable-features=LazyFrameLoading,LazyImageLoading,TabGridLayoutAndroid --flag-switches-end

Das Problem ist eine CFI-Verletzung, die im AOSP-Code gefangen ist, und nicht in Chromium. Es ist jedoch derzeit nicht bekannt, ob es sich um einen AOSP-Fehler oder einen Chromium-Fehler handelt. Es könnte sein, dass Chromium einen Funktionszeiger mit einem ungültigen Typ übergibt. Es ist genau bekannt, wo der Aufruf des Funktionszeigers auftritt, der die CFI-Verletzung auslöst, aber wir haben die aufgerufene Funktion noch nicht identifiziert und wie sie CFI verletzt. Es ist ein bisschen schmerzhaft, wie es die Grenzen dieser Programme überschreitet.

https://github.com/GrapheneOS/platform_frameworks_av/commit/7f7b234d7c05c3bdb304d886a317fd895e18021e deaktiviert vorübergehend die CFI-Erzwingung für diese Funktion, während wir daran arbeiten. Es ist etwas, bei dem wir wirklich Hilfe gebrauchen könnten, wenn jemand über Programmiererfahrung auf niedrigem Niveau und Zeit verfügt, um dies zu debuggen. Ich persönlich habe keine Zeit dafür, und es ist nur eines von einem Dutzend solcher Probleme, bei denen ich es vorübergehend umgehen musste, während ich auf Hilfe wartete.

Könnte ich diese Woche irgendwann mal versuchen

@nikolowry keine Sorge, ich werde es selbst versuchen. Können Sie damit beginnen, diese Flags auf die Standardeinstellungen zurückzusetzen, bis Sie den Absturz reproduzieren können?

@csagan5 setze gpu-bezogene Flags auf Standard, deaktivierte "GPU-Rendering

Ich sehe, Sie haben den Titel aktualisiert, um "Android 10" aufzunehmen, aber lassen Sie mich wissen, wenn ich etwas vermisse, das auf 9 repliziert werden soll

@nikolowry Soweit mir bekannt ist, deckt der aktuelle Patch in Bromite Android < 10 ab, sodass das Upstream-Problem nur auf Android 10 beschränkt ist

@csagan5 gotcha, ich

Ich habe die neueste Version von Bromite mit is_cfi=false . Benutzer, bei denen der Absturz auftritt, setzen Sie bitte das Flag #disable-accelerated-video-decode auf die Standardeinstellung zurück und testen Sie mit dieser Version: https://fdroid.bromite.org/ bromit/rel_80.0.3987.95_arm64_ChromeModernPublic_nocfi.apk

Habe gerade die Nocfi-Version getestet, Android 10, Hardware-Videodecodierung aktiviert. Absturz mit der gleichen Fehlermeldung wie zuvor.
GpuProcessHost: The GPU process was protected from out of memory kill

Ich denke, es ist ein vollständiger AOSP-Fehler und der Grund, warum er nicht vom Upstream ausgelöst wird, ist, dass sie keine 64-Bit-Builds verwenden. Das Deaktivieren von CFI in Chromium würde es wahrscheinlich umgehen, wenn der fehlerhafte Funktionszeiger in Chromium wäre, aber es scheint, dass es sich um einen AOSP-Codebase-Funktionszeiger handelt. Das Problem kann subtiler sein als nur ein falsch eingegebener Funktionszeiger, der eine CFI-Verletzung auslöst, was erklären würde, warum wir Probleme beim Debuggen hatten.

@aluo-x kannst du den Absturz teilen? nur um nachzusehen, ob sich etwas im Vergleich zum CFI geändert hat

@thestinger Wenn ich in der Chromium-Codebasis

@csagan5 wird es tun. Aber frühestens kann ich ziehen es wird wohl am 20. sein. Bis dahin super beschäftigt.

Das eigentliche Upstream-Problem könnte sein: https://bugs.chromium.org/p/chromium/issues/detail?id=838725

@aluo-x kannst du bitte auch testen, ob das Aktivieren des Flags #enable-oop-rasterization einen Effekt hat? Es war zuvor standardmäßig in v79 aktiviert, jetzt jedoch deaktiviert.

@csagan5 scheint abzustürzen,

@aluo-x danke für deine Tests; Falls Sie oder jemand anderes Tests auf Android10 fortsetzen möchte, habe ich eine andere Version erstellt, die einige Änderungen zwischen v79 und v80 bezüglich AImageReader rückgängig macht: https://fdroid.bromite.org/bromite/rel_80.0.3987.95_arm64_ChromeModernPublic_nocfi_bugbl .apk

Bitte melden Sie sich, wenn dies den Absturz behebt oder nicht.

Hier patchen: https://github.com/bromite/bromite/pull/491

@csagan5 das macht den Trick! Keine Abstürze mehr mit Hardware-Videodecodierung

@aluo-x großartig! Danke fürs Testen. Ich fand die Lösung von in einem diff zwischen v79 und v80 suchen, ist das Patch von Upstream vorgeschlagen nicht vollständig deaktivieren AImageReader , während die schwarze Liste v79 GPU Wiederherstellung für den Trick.

Ich werde den Fix für die nächste Version von Bromite veröffentlichen; @thestinger Sie können auch den Patch für Vanadium auswählen.

@aluo-x danke für deine Tests; Falls Sie oder jemand anderes Tests auf Android10 fortsetzen möchte, habe ich eine andere Version erstellt, die einige Änderungen zwischen v79 und v80 bezüglich AImageReader rückgängig macht: https://fdroid.bromite.org/bromite/rel_80.0.3987.95_arm64_ChromeModernPublic_nocfi_bugbl .apk

Bitte melden Sie sich, wenn dies den Absturz behebt oder nicht.

Patch hier: #491

Funktioniert bei mir nicht auf Android 10 Stock ZTE axon ... Bromite ist auch beim Abspielen von Facebook-Videos kaputt ... Nach der Installation der gepatchten apk

@yasars bitte melden Sie den gefundenen Absturz mit adb logcat und stellen Sie sicher, dass er direkt nach dem Absturz generiert wird.

@csagan5 Ich denke, es ist letztendlich ein AOSP-Fehler und was mit Chromium passiert, ist, dass sie AImageReader zunehmend verwenden und keine Möglichkeit mehr haben, dies zu vermeiden.

Ich denke, es ist letztendlich ein AOSP-Fehler und was mit Chromium passiert, ist, dass sie AImageReader zunehmend verwenden und keine Möglichkeit mehr haben, dies zu vermeiden.

@thestinger der disable_aimagereader GPU-Workaround wird weiterhin unterstützt: https://github.com/chromium/chromium/search?q=disable_aimagereader&type=Code
Die einzigen Änderungen im Zusammenhang mit AImageReader zwischen v79 und v80 betrafen diese Problemumgehung für ARM-Geräte, daher schließe ich, dass dies in Zukunft passieren könnte, aber wir sind noch nicht am Ziel; Wenn AImageReader um disable_aimagereader teilweise deaktiviert wurde, würden auch die anderen Geräte mit den für die Problemumgehung markierten GPUs abstürzen.

Das ARM-Blacklist-Flag wurde eingeführt , um diese beiden Upstream-Probleme zu beheben:

• https://bugs.chromium.org/p/chromium/issues/detail?id=951832
• https://bugs.chromium.org/p/chromium/issues/detail?id=838725

Im zweiten wird die Strategie hinter diesen Änderungen besser erklärt (es erklärt auch, dass AImageReader dynamisch geladen wird, um abwärtskompatibel zu sein).

Es stellt sich heraus (#497), dass das, was den Absturz auf Android 10 behebt, ihn für Android 9 einführen wird, obwohl ich noch kein Protokoll sehen konnte. @nikolowry vielleicht kannst du das einreichen, wenn du es am 9 reproduzieren kannst

Das Problem auf Android9 liegt daran, dass die Problemumgehung disable_aimagereader nicht aktiviert ist. In der nächsten Version werde ich es sowohl für Android9 als auch für Android10 für ARM64-CPUs aktivieren.

Dies sollte hoffentlich der beste Kompromiss sein, bis der NDK-Bug behoben ist.

Ich habe die neueste Version (80.0.3987.109) auf Android 9 installiert und stoße jetzt auf die App, die abstürzt, wenn ich bei Google nach etwas suche, das Youtube-Videos anzeigt. Es beginnt wie eine kleine Vorschau (ein paar Bilder) dieses Videos und dann erscheint das Absturz-Popup. Wenn ich auf "App schließen" klicke, wird nur das Popup geschlossen, die App jedoch geöffnet.

Ich habe das Telefon an meinen Laptop angeschlossen und versucht, logcat auszuführen, während ich versuche, es zu reproduzieren. Hoffentlich hilft diese Logcat-Ausgabe:

--------- beginning of crash
02-21 22:32:26.065  5895  6029 F libc    : Fatal signal 6 (SIGABRT), code -6 (SI_TKILL) in tid 6029 (ImageReader-1x1), pid 5895 (ileged_process0)
02-21 22:32:26.149  6042  6042 F DEBUG   : *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
02-21 22:32:26.149  6042  6042 F DEBUG   : Build fingerprint: 'htc/ocmdugl_00401/htc_ocmdugl:9/PPRL.190405.003/1088049.2:user/release-keys'
02-21 22:32:26.149  6042  6042 F DEBUG   : Revision: '0'
02-21 22:32:26.149  6042  6042 F DEBUG   : ABI: 'arm64'
02-21 22:32:26.149  6042  6042 F DEBUG   : pid: 5895, tid: 6029, name: ImageReader-1x1  >>> org.bromite.bromite:privileged_process0 <<<
02-21 22:32:26.149  6042  6042 F DEBUG   : signal 6 (SIGABRT), code -6 (SI_TKILL), fault addr --------
02-21 22:32:26.149  6042  6042 F DEBUG   :     x0  0000000000000000  x1  000000000000178d  x2  0000000000000006  x3  0000000000000008
02-21 22:32:26.149  6042  6042 F DEBUG   :     x4  612d66716e2e6f6f  x5  612d66716e2e6f6f  x6  612d66716e2e6f6f  x7  7f7f7f7f7f7f7f7f
02-21 22:32:26.149  6042  6042 F DEBUG   :     x8  0000000000000083  x9  1a26e64784f6a511  x10 0000000000000000  x11 fffffffc7ffffbdf
02-21 22:32:26.150  6042  6042 F DEBUG   :     x12 0000000000000001  x13 000000005e504c69  x14 0039ef1efb72b6e2  x15 00007df16a1486fd
02-21 22:32:26.150  6042  6042 F DEBUG   :     x16 0000007a698722a8  x17 0000007a697b0250  x18 0000000000000001  x19 0000000000001707
02-21 22:32:26.150  6042  6042 F DEBUG   :     x20 000000000000178d  x21 649aaa0af867eead  x22 0000007a6a6dd240  x23 0000007a65c73960
02-21 22:32:26.150  6042  6042 F DEBUG   :     x24 0000007a65c74410  x25 00000079c8802000  x26 00000079cb3a9588  x27 0000000000000000
02-21 22:32:26.150  6042  6042 F DEBUG   :     x28 00000079e13fb350  x29 00000079c88ff140
02-21 22:32:26.150  6042  6042 F DEBUG   :     sp  00000079c88ff100  lr  0000007a697a4d7c  pc  0000007a697a4da4
02-21 22:32:26.164  6042  6042 F DEBUG   : 
02-21 22:32:26.164  6042  6042 F DEBUG   : backtrace:
02-21 22:32:26.164  6042  6042 F DEBUG   :     #00 pc 0000000000021da4  /system/lib64/libc.so (abort+116)
02-21 22:32:26.164  6042  6042 F DEBUG   :     #01 pc 000000000001dac8  /system/lib64/libclang_rt.ubsan_standalone-aarch64-android.so (__sanitizer::Abort()+56)
02-21 22:32:26.164  6042  6042 F DEBUG   :     #02 pc 000000000001b688  /system/lib64/libclang_rt.ubsan_standalone-aarch64-android.so (__sanitizer::Die()+164)
02-21 22:32:26.164  6042  6042 F DEBUG   :     #03 pc 0000000000026b6c  /system/lib64/libclang_rt.ubsan_standalone-aarch64-android.so (__ubsan_handle_cfi_check_fail_abort+68)
02-21 22:32:26.164  6042  6042 F DEBUG   :     #04 pc 0000000000014084  /system/lib64/libmediandk.so (__cfi_check_fail+108)
02-21 22:32:26.164  6042  6042 F DEBUG   :     #05 pc 000000000001ac14  /system/lib64/libmediandk.so (__cfi_check+7188)
02-21 22:32:26.164  6042  6042 F DEBUG   :     #06 pc 00000000000224a4  /system/bin/linker64 (__dl__ZN15CFIShadowWriter7CfiFailEmPvS0_S0_+128)
02-21 22:32:26.164  6042  6042 F DEBUG   :     #07 pc 0000000000001140  /system/lib64/libdl.so (__cfi_slowpath_diag+64)
02-21 22:32:26.164  6042  6042 F DEBUG   :     #08 pc 0000000000026fd8  /system/lib64/libmediandk.so (AImageReader::CallbackHandler::onMessageReceived(android::sp<android::AMessage> const&)+520)
02-21 22:32:26.164  6042  6042 F DEBUG   :     #09 pc 0000000000019904  /system/lib64/libstagefright_foundation.so (android::AHandler::deliverMessage(android::sp<android::AMessage> const&)+92)
02-21 22:32:26.164  6042  6042 F DEBUG   :     #10 pc 0000000000020f70  /system/lib64/libstagefright_foundation.so (android::AMessage::deliver()+180)
02-21 22:32:26.164  6042  6042 F DEBUG   :     #11 pc 000000000001c490  /system/lib64/libstagefright_foundation.so (android::ALooper::loop()+556)
02-21 22:32:26.164  6042  6042 F DEBUG   :     #12 pc 000000000000f9d4  /system/lib64/libutils.so (android::Thread::_threadLoop(void*)+280)
02-21 22:32:26.164  6042  6042 F DEBUG   :     #13 pc 00000000000b590c  /system/lib64/libandroid_runtime.so (android::AndroidRuntime::javaThreadShell(void*)+140)
02-21 22:32:26.164  6042  6042 F DEBUG   :     #14 pc 0000000000082dc8  /system/lib64/libc.so (__pthread_start(void*)+36)
02-21 22:32:26.164  6042  6042 F DEBUG   :     #15 pc 00000000000235f8  /system/lib64/libc.so (__start_thread+68)
02-21 22:32:26.398  3073  3092 I ActivityManager: Showing crash dialog for package org.bromite.bromite u0

Wenn das nicht nötig ist, mache ich den Logcat-Lauf gerne wieder, wenn ihr mir Hinweise geben könnt, was ich tun muss

@HigH-HawK das Problem wurde in 80.0.3987.118 für beide Android9/Android10 ARM64-Geräte behoben

@csagan5 Wow das war schnell 😄 Ich habe gerade die neue Version installiert und kann bestätigen, dass es behoben ist. Tolle Arbeit 👍

Alle Probleme scheinen mit der nativen Android-Unterstützung von AImageReader zusammenzuhängen und wahrscheinlich spielt auch das dynamische Laden in Chromium eine Rolle; Benutzer, die die Hardware-Videodecodierung mit #disable-accelerated-video-decode deaktiviert haben, können sie jetzt auf die Standardeinstellungen zurücksetzen, da sie sicher eingeschaltet werden können.

Vielen Dank nach vielen Malen ... Sie beheben diesen schrecklichen Fehler thx dev @csagan5

Letztes Update hat alle Probleme behoben :)

@thestinger Upstream lässt den disable_aimagereader Workaround von v81 fallen: https://github.com/chromium/chromium/commit/dcd5a39518246eb999f1cc63bf1ec95d93fd5b2f

Ich werde es rückgängig machen und die Problemumgehung beibehalten, bis bestätigt wird, dass es nicht mehr benötigt wird.

Upstream hat das gleiche in v81 getan: chromium/ chromium@28955702ab5514868951f4417582d5af958f9cc0

Bitte bestätigen Sie, dass dieses Problem in den neuesten 81.0.4044.63 noch behoben ist

Bestätigt für 81.0.4044.63

Habe Bromite (81.0.4044.63) heute auf LineageOS 17.1 Kuntao (Testbuild) installiert und kann bestätigen, dass es immer noch abstürzt. Entweder auf Vimeo-Link im Ticket und YouTube. Bei YT tritt der erste Absturz normalerweise nach zwei Sekunden Wiedergabe auf. Einige Videos werden nach einem Absturz einwandfrei wiedergegeben, wenn sich die Seite selbst aktualisiert, jedoch nur bei Auflösungen unter 720p.
Dieses ROM hat leider vorerst einige Audioprobleme, aber ich kann bestätigen, dass alles im Jelly Browser richtig funktioniert, also denke ich, dass es wahrscheinlich kein Lineage-Fehler ist.
Logcat
Sie können zum Absturz zu Zeile 201 springen.

Stürzt auch hier immer noch ab, aber nicht mehr wie zuvor. Jetzt ist es nur noch ein Videofehler, die App selbst stürzt nicht ab. Ich vermute, dass es etwas mit Apex-Updates zu tun hat. Seltsamerweise funktioniert v80.0.3987.118 einwandfrei.

Nach dem Update von Bromite v80.0.3987.118 auf Bromite v81.0.4044.63 stürzt das Video erneut ab.

@kyelbek @deadbabe @Jaminanim Welche Android- Version verwendest du? Welche GPU? Ich gehe davon aus, dass Sie das arm64 ChromeModernPublic APK installiert haben.

@csagan5 Android 10; Adreno 640; ja, ich habe arm64_ChromeModernPublic.apk installiert.

@csagan5 Android 10, SD625 (Adreno 506) und ja, arm64 sdk21+, also ist es eine moderne APK, wenn ich mich richtig erinnere.

OK danke; sieht so aus, als hätte der Upstream-Patch etwas ausgelassen, ich werde mich darum kümmern, dies bei der nächsten Bromite-Version zu beheben.

Das Setzen von chrome ://flags/# disable -accelerated-video-decode auf deaktiviert behebt den Absturz für mich vorerst.

Das Setzen von chrome ://flags/# disable -accelerated-video-decode auf deaktiviert behebt den Absturz für mich vorerst.

Für mich führt dies nur zu einer teilweisen Abschwächung: Das Deaktivieren der beschleunigten Videodecodierung führt dazu, dass m.youtube.com-Videos einwandfrei abgespielt werden, aber auf m.facebook.com bleibt das Video bei 0:00 eingefroren.

Wenn ich es wieder aktiviere, scheint das Verhalten das gleiche zu sein, das ich vor der letzten Korrektur hatte. Ich verwende OnePlus 6, Android 10, Oxygen OS 10.3.2.

@kyelbek @Jaminanim @valpamp ihr alle habt Adreno GPUs und ARM64 CPUs; Können Sie bitte zu chrome://gpu und mir Folgendes erzählen:

• ist disable_aimagereader in der Treiber-Fehlerumgehungsliste?
• dein GL_VENDOR

Der Upstream-Patch hat einige Änderungen im Zusammenhang mit diesem Bugfix übrig gelassen, ich werde versuchen, sie nach Ihrem Feedback wieder einzuführen.

Ich habe der Problembeschreibung eine Tabelle hinzugefügt, um den Status zu verfolgen.

aber auf m.facebook.com bleibt das Video bei 0:00 eingefroren.

@valpamp können Sie überprüfen, ob es Abstürze in adb logcat ? Es könnte ein anderer Fehler sein.

Obwohl nicht an mich adressiert:
disable_aimagereader ist in der Workaround-Liste und GL_VENDOR = Qualcomm

Obwohl nicht an mich adressiert:

@scanno Ich habe dich nicht

Ich verwende ARM64 und habe eine Adreno 640.
Ehrlich gesagt muss ich hinzufügen, dass ich selbst baue.

@scanno , das später nützlich sein kann, um Patches zu testen, aber im Moment müssen wir mit dem offiziellen Bromite-Build testen, um einen einheitlichen Test zu haben und Build-Störungen zu vermeiden (wie es @renlord zuvor

Da Sie disable_aimagereader in Ihrer Workaround-Liste haben, können Sie hier die adb logcat des Absturzes eintragen? Denken Sie daran, disable-accelerated-video-decode vor dem Test rückgängig zu machen.

@csagan5
disable_aimagereader ist nicht aufgeführt.
GL_VENDOR: Qualcomm

@csagan5 muss sehen, ob mein Build und das offizielle Bromite nebeneinander installiert werden können, da sich der persönliche Build als Teil meines eigenen Android-

Ah vergiss es. Anderer Paketname.

@csagan5 aus dem ARM64-Bromite-Build:
```
03-18 09:29:02.195 F/DEBUG (20548): *
03-18 09:29:02.195 F/DEBUG (20548): Fingerabdruck erstellen: 'Xiaomi/raphael_eea/raphael:10/QKQ1.190825.002/V11.0.5.0.QFKEUXM:user/release-keys'
03-18 09:29:02.195 F/DEBUG (20548): Revision: '0'
03-18 09:29:02.195 F/DEBUG (20548): ABI: 'arm64'
18.03. 09:29:02.196 F/DEBUG (20548): Zeitstempel: 18.03.2020 09:29:02+0100
03-18 09:29:02.196 F/DEBUG (20548): pid: 20496, tid: 20526, Name: ImageReader-1x1 >>> org.bromit. bromit:privileged_process1 <<<
03-18 09:29:02.196 F/DEBUG (20548): UID: 10162
03-18 09:29:02.196 F/DEBUG (20548): Signal 6 (SIGABRT), Code -6 (SI_TKILL), Fehleradresse --------
03-18 09:29:02.196 F/DEBUG (20548): x0 0000000000000000 x1 000000000000502e x2 0000000000000006 x3 0000007afff2d9a0
03-18 09:29:02.196 F/DEBUG (20548): x4 0000000000000080 x5 0000000000000080 x6 0000000000000080 x7 ff6a626467625e68
03-18 09:29:02.196 F/DEBUG (20548): x8 00000000000000f0 x9 bc37eb2703ed0008 x10 0000000000000001 x11 0000000000000000
03-18 09:29:02.196 F/DEBUG (20548): x12 fffffff0fffffbdf x13 0000000000000158 x14 0002cea4d3da8dbd x15 000000002e3caf88
03-18 09:29:02.196 F/DEBUG (20548): x16 0000007bf34568c0 x17 0000007bf34340e0 x18 0000007afe2ba000 x19 0000000000005010
03-18 09:29:02.196 F/DEBUG (20548): x20 000000000000502e x21 00000000ffffffff x22 0000007bf41126e0 x23 0000007afff2dbc0
03-18 09:29:02.196 F/DEBUG (20548): x24 0000007afff2e020 x25 0000007afff2dd50 x26 0000007afff2e020 x27 0000007b637f2020
03-18 09:29:02.196 F/DEBUG (20548): x28 0000000000000000 x29 0000007afff2da40
03-18 09:29:02.196 F/DEBUG (20548): sp 0000007afff2d980 lr 0000007bf33e8f48 pc 0000007bf33e8f74
03-18 09:29:02.209 F/DEBUG (20548):
03-18 09:29:02.209 F/DEBUG (20548): Rückverfolgung:
03-18 09:29:02.209 F/DEBUG (20548): #00 pc 0000000000081f74 /apex/com.android.runtime/lib64/bionic/libc.so (abort+160) (BuildId: 67d12a65ecd9b3b007b36a5324b4cc31)
03-18 09:29:02.209 F/DEBUG (20548): #01 pc 00000000000186d8 /system/lib64/libmediandk.so (__cfi_check_fail+24) (BuildId: e7bf8c29e72edf89814e59adacc499b8)
03-18 09:29:02.209 F/DEBUG (20548): #02 pc 000000000001ade4 /system/lib64/libmediandk.so (__cfi_check+7652) (BuildId: e7bf8c29e72edf89814e59adacc499b8)
03-18 09:29:02.209 F/DEBUG (20548): #03 pc 00000000000476b4 /apex/com.android.runtime/bin/linker64 (__dl__ZN15CFIShadowWriter7CfiFailEmPvS0_S0_+124) (BuildId: 3282bb4ec077199f1b358f)
03-18 09:29:02.209 F/DEBUG (20548): #04 pc 0000000000001144 /apex/com.android.runtime/lib64/bionic/libdl.so (__cfi_slowpath+64) (BuildId: ee5a54c32874d345e4d2f02a4cbace8a)
03-18 09:29:02.209 F/DEBUG (20548): #05 pc 0000000000029edc /system/lib64/libmediandk.so (AImageReader::CallbackHandler::onMessageReceived(android::sp<:amessage i="48"> const& )+456) (BuildId: e7bf8c29e72edf89814e59adacc499b8)
03-18 09:29:02.209 F/DEBUG (20548): #06 pc 00000000000168b4 /system/lib64/libstagefright_foundation.so (android::AHandler::deliverMessage(android::sp<:amessage i="50"> const& )+48) (BuildId: 56d46d1e5583b3c4c5065b0726c0f3e5)
03-18 09:29:02.209 F/DEBUG (20548): #07 pc 000000000001a324 /system/lib64/libstagefright_foundation.so (android::AMessage::deliver()+100) (BuildId: 56d46d1e5583b3c4c5065b0726c0f3e5)
03-18 09:29:02.210 F/DEBUG (20548): #08 pc 00000000000172fc /system/lib64/libstagefright_foundation.so (android::ALooper::loop()+560) (BuildId: 56d46d1e5583b3c4c5065b0726c0f3e5)
03-18 09:29:02.210 F/DEBUG (20548): #09 pc 000000000001361c /system/lib64/libutils.so (android::Thread::_threadLoop(void)+316) (BuildId: 0b777f39593103e3b0e56138d7a31fb6)
03-18 09:29:02.210 F/DEBUG (20548): #10 pc 00000000000c2b80 /system/lib64/libandroid_runtime.so (android::AndroidRuntime::javaThreadShell(void )+140) (BuildId: 338bb88f440565302388ebcd064c77cc)03-18 09:29:02.210 F/DEBUG (20548): #11 pc 00000000000e10d8 /apex/com.android.runtime/lib64/bionic/libc.so (__pthread_start(void )+36) (BuildId: 67d12a65ecd9b3b007b36a5324b4cc31)
03-18 09:29:02.210 F/DEBUG (20548): #12 pc 0000000000083ab0 /apex/com.android.runtime/lib64/bionic/libc.so (__start_thread+64) (BuildId: 67d12a65ecd9b3b007b36a5324b4cc31)
````

Und ja, disable_aimagereader ist in Workarounds für Treiberfehler aufgeführt

@kyelbek @Jaminanim @valpamp ihr alle habt Adreno GPUs und ARM64 CPUs; Können Sie bitte zu chrome://gpu und mir Folgendes erzählen:

* is `disable_aimagereader` in the driver bug workarounds list?

* your `GL_VENDOR`

Der Upstream-Patch hat einige Änderungen im Zusammenhang mit diesem Bugfix übrig gelassen, ich werde versuchen, sie nach Ihrem Feedback wieder einzuführen.

Ich habe der Problembeschreibung eine Tabelle hinzugefügt, um den Status zu verfolgen.

aber auf m.facebook.com bleibt das Video bei 0:00 eingefroren.

@valpamp können Sie überprüfen, ob es Abstürze in adb logcat ? Es könnte ein anderer Fehler sein.

disable_aimagereader ist in der Liste Treiberfehler-Workarounds und GL_VENDOR = Qualcomm.

Dies ist die Ausgabe von adb logcat, ich hoffe, ich habe die relevanten Zeilen erkannt:
logcat.txt

disable_aimagereader ist in der Liste Treiberfehler-Workarounds und GL_VENDOR = Qualcomm.

Dies ist die Ausgabe von adb logcat, ich hoffe, ich habe die relevanten Zeilen erkannt:
logcat.txt

Danke, dass du diese @valpamp gemeldet hast. Ich kann nur chromium: [WARNING:gpu_process_host.cc(1204)] The GPU process has crashed 1 time(s) in deinem Log sehen, siehst du einen Block wie in diesem Kommentar ?

Und ja, disable_aimagereader ist in Workarounds für Treiberfehler aufgeführt

@scanno Wenn Sie disable_aimagereader haben, sollte es bei AImageReader keinen Absturz geben, das ist seltsam.

disable_aimagereader ist nicht aufgeführt.
GL_VENDOR: Qualcomm

@Jaminanim kannst du bitte den Test mit dieser Version wiederholen? https://fdroid.bromite.org/bromite/rel_81.0.4044.70_arm64_ChromeModernPublic_sf.apk

@csagan5 in der Tat seltsam

Werde auf einem anderen Telefon nachsehen, dort stürzt auch Bromit ab (Adreno 630). Auch disable_aimagereader ist auf diesem Telefon aufgeführt.

@csagan5 disable_aimagereader steht in meinem Fall auf der Workaround-Liste, GL_VENDOR = Qualcomm.
Ich habe beim Bereitstellen meines Logcat keine Chrome-Flags angerührt, aber ich habe jetzt die HW-Beschleunigung zu Testzwecken deaktiviert und kann bestätigen, dass Vimeo-, YouTube- und Instagram/Facebook-Videos jetzt korrekt funktionieren.

Danke, dass du diese @valpamp gemeldet hast. Ich kann nur chromium: [WARNING:gpu_process_host.cc(1204)] The GPU process has crashed 1 time(s) in deinem Log sehen, siehst du einen Block wie in diesem Kommentar ?

Gefunden, los gehts:
logcat.txt

Vielen Dank für Ihre tolle Arbeit.

@valpamp aus dem Crash-Dump sieht es genauso aus wie die anderen, ein Absturz im Zusammenhang mit AImageReader. Allerdings finde ich es seltsam, dass es bei dir nicht auf YouTube passiert.

@scanno @kyelbek @valpamp es scheint, dass disable_aimagereader in v81 für Android10 nicht mehr effektiv ist. Kannst du bitte mit dieser APK testen? https://fdroid.bromite.org/bromite/rel_81.0.4044.70_arm64_ChromeModernPublic_sf.apk

Test sollte ohne das Flag disable-hw-video-decode .

@aluo-x vielleicht könnten Sie auch testen, um zu bestätigen, dass in v81 disable_aimagereader nicht funktioniert; Ich habe zu diesem Thema eine Tabelle erstellt, um die verschiedenen GPUs zu verfolgen, da wir eine überwältigende Mehrheit von Adrenos haben.

Ich kann bestätigen, dass v81 64-Bit-Bromite für mich beim Abspielen von Videos einfriert, Mali-GPU.
Bearbeiten: Um zu verdeutlichen, dass es sich um Aktienbromit handelt, wurden keine Einstellungen geändert.

@scanno @kyelbek @valpamp es scheint, dass disable_aimagereader in v81 für Android10 nicht mehr effektiv ist. Kannst du bitte mit dieser APK testen? https://fdroid.bromite.org/bromite/rel_81.0.4044.70_arm64_ChromeModernPublic_sf.apk

Test sollte ohne das Flag disable-hw-video-decode .

Getestet auf m.facebook.com, m.youtube.com und vimeo.com und funktioniert bei mir einwandfrei.

@csagan5 quicky getestet, scheint den Absturz auch hier zu lösen

@csagan5 Dieser Build funktioniert wie er sollte. Gut gemacht!

Ich kann bestätigen, dass v81 64-Bit-Bromite für mich beim Abspielen von Videos einfriert, Mali-GPU.
Bearbeiten: Um zu verdeutlichen, dass es sich um Aktienbromit handelt, wurden keine Einstellungen geändert.

@aluo-x super, danke für deinen Test. Könnten Sie auch mit https://fdroid.bromite.org/bromite/rel_81.0.4044.70_arm64_ChromeModernPublic_sf.apk (nächste Version) testen, um zu überprüfen, ob es den Absturz auch für Sie behebt?

@csagan5 Ich habe es installiert und hatte keine Abstürze. Im Abschnitt "Info" scheint dies jedoch die 32-Bit-Version zu sein?

@csagan5 Ich habe es installiert und hatte keine Abstürze. Im Abschnitt "Info" scheint dies jedoch die 32-Bit-Version zu sein?

chrome://version erwähnt hier 64 Bit

@csagan5 Ich habe es installiert und hatte keine Abstürze. Im Abschnitt "Info" scheint dies jedoch die 32-Bit-Version zu sein?

chrome://version erwähnt hier 64 Bit

Ich auch.

Mein Fehler. Du hast Recht, es ist 64bit

Okay, danke an alle fürs Testen. Ich werde demnächst eine neue Version mit dem Fix veröffentlichen, den Upstream ausgelassen hat .

Behoben in 81.0.4044.70 .

@csagan5 dieser Fix hat es tatsächlich für mich kaputt gemacht, als es vorher nicht kaputt war
https://del.dog/eaqumophyc
Ich würde ein Flag hinzufügen, um den Fix zu kontrollieren

Für mich hat die Installation der "fixen" Version über der "kaputten" Version meinen Adblock gebrochen. Aber das Deinstallieren des alten und das Installieren des neuen hat den Adblock wieder behoben.

Wie testest du den Adblock? ich glaube nicht das es bei mir funktioniert

https://ads-blocker.com/testing/
Wenn Doubleclick-/Google-Anzeigen angezeigt werden, funktioniert es nicht. Aber auch hier wurde das Problem behoben, indem die alte Installation entfernt und die neue erneut installiert wurde.

wow das ist verwirrend
mein Aurora Droid ist kaputt und ich habe nicht aktualisiert und ich habe nicht bemerkt, dass es .63, nicht .70 . war
jetzt ist es behoben

@r3muxd Redest du von Videowiedergabe oder Adblock? Wurde es mit einer sauberen Installation behoben?

https://ads-blocker.com/testing/
Wenn Doubleclick-/Google-Anzeigen angezeigt werden, funktioniert es nicht. Aber auch hier wurde das Problem behoben, indem die alte Installation entfernt und die neue erneut installiert wurde.

@aluo-x beim Installieren oder Deinstallieren der App wird geschlossen. Wenn die App erneut gestartet wird, sucht sie nach neuen Filtern und lädt diese herunter. Die Filter wurden nach der Version v81 aktualisiert. Ihre erste Installation hat also die "aktuellen" Filter erhalten, die keine Filter für Doubleclick-/Google-Anzeigen enthielten (eine Regression von #423), als Sie sie erneut installierten, wurden die Filter aktualisiert und enthielten den Bugfix für #423.

Dieser Fix hat es tatsächlich für mich kaputt gemacht, als es vorher nicht kaputt war
https://del.dog/eaqumophyc
Ich würde ein Flag hinzufügen, um den Fix zu kontrollieren

@r3muxd bitte melde deine Bromite-Version; erwähnt Ihr chrome://gpu disable_aimagereader ? Irgendwelche benutzerdefinierten Flags, die Sie in chrome://flags ?

für mich war das Problem bei 80 nicht da, war bei 81.0.4044.63 vorhanden und verschwand auf 81.0.4044.76
mein Aurora-Laden war kaputt und zeigte mir, dass 4044.63 die neueste Version war und ich nur die ersten 3 Oktette bemerkt habe

Es gab noch Änderungen im Upstream in der Handhabung von AImageReader ; Alle korrekten Patches sollten in der neuesten Bromite-Version ( 83.0.4103.46 ) enthalten sein. Bitte posten Sie hier, wenn Sie Probleme im Zusammenhang mit Videoabstürzen finden.

Ich bin mir nicht sicher, ob noch jemand Probleme hatte. Aber bei jeder Veröffentlichung von Bromite 83 hatte ich häufiges Einfrieren. Es scheint auf bestimmten Websites mit automatischer Videowiedergabe häufig ausgelöst zu werden (z. B. imgur). Das Einfrieren ist ein weiches Einfrieren, und ich kann wieder interagieren, nachdem ich Chrome minimiert und dann wieder zu Chrome gewechselt habe. Plattform ist Android 10.1

chrome://gpu zeigt keine Fehler an

Ich habe die Versionen Arm64 und Arm32 ausprobiert, beide haben Freezes, aber Arm64 scheint häufiger zu sein.

Tatsächlich kann sogar das Abspielen von Videos von imgur auf m.reddit.com, das Klicken nach vorne und das Zurückkehren zu einem automatisch fortsetzenden Video das Einfrieren auslösen.

Aber mit jeder Veröffentlichung von Bromite 83

Sie müssen es melden, wenn es passiert, einschließlich der Versionsnummer und des Absturzprotokolls.

Tatsächlich kann sogar das Abspielen von Videos von imgur auf m.reddit.com, das Klicken nach vorne und das Zurückkehren zu einem automatisch fortsetzenden Video das Einfrieren auslösen.

Hast du ein Crashlog? Es könnte eine Regression in v83 sein.

Gute Argumente. Ich habe gezögert, einen Fehler zu melden, da ich ihn nicht konsequent reproduzieren kann. Es werden keine Fehler in chrome://gpu ausgegeben , und Bromite stürzt nicht ab, sondern friert nur ein, bis ich wegschalte und dann wieder zurückwechsele.

Habe gerade die arm32-Version getestet und friert definitiv viel weniger ein als die arm64-Version. Hoffentlich behebt Version 84 von Chrome diese Regression.

@aluo-x Der einzige Weg nach vorn wäre, den Upstream-Problem-Tracker zu überprüfen und / oder den Android Studio-Profiler anzuhängen, um zu sehen, was los ist.

https://www.androidcentral.com/chrome-android-finally-get-64-bit-variant-and-much-better-performance

Anscheinend hat Google Chrome 84 mit 64-Bit-Builds getestet. Vielleicht ist die Umgehung nicht mehr nötig?

Für Interessierte führe ich einige Tests für v86 in #755 durch

Ich werde AImageReader für Qualcomm-Chipsätze deaktivieren, siehe Diskussion in Nr. 814 bei Interesse.