firefox stützt sofort ab

[frankw]

Hallo,

ich versuche firefox in meinem tightvnc-server zu starten, ging sonst auch immer, aber vermutlich durch die letzten Sicherheitsupdates geht das nicht mehr (lief schon über einen Monat durch)...leider habe ich keine Möglichkeit gefunden, zu einer sinnvollen Fehlermeldung zu kommen. Es kommt einfach nur der Crash-Dialog....sofort beim start und auch im safe-mode. Ich habe sogar den Container komplett neu aufgesetzt, ohne Erfolg.

Ich habe auch bereits über apt-cache policy eine ältere Version installiert, auch ohne Erfolg.
Kann man irgendwie noch weiter downgraden oder eine ältere Version herunterladen (armhf Architektur)

habe jetzt grob über den Weg hier die Version 52 installiert, die geht auf ohne abzustützen...ist natürlich alles andere als sauber. von daher wäre es interessant, wie ich der neuen Version irgendeine sinnvolle Fehlermeldung entlocken kann..

Gruß Frank

[snyborg]

Hi Frank,

starte mal mit strace...

[frankw]

habs mal in eine Log geschrieben und hier hochgeladen:

https://drive.google.com/open?id=13Ypji ... IH7hikW7ri

[tobo]

Sicher doch. Zeige erstmal die Plaintext-Konsolenausgabe von:

Code: Alles auswählen

$ firefox --verbose

[frankw]

Code: Alles auswählen

ExceptionHandler::GenerateDump cloned child 267ExceptionHandler::WaitForContinueSignal waiting for continue signal...

ExceptionHandler::SendContinueSignalToChild sent continue signal to child
Xlib:  extension "XInputExtension" missing on display ":1".
Xlib:  extension "XInputExtension" missing on display ":1".

[tobo]

Was man so liest, sieht das nach einem VNC-X11-Problem aus. Funktionieren denn andere X11-Programme? Testweise kannst du mal diesen ziemlich gruseligen Hack versuchen, der wohl mehrheitlich den Leuten Erfolg brachte:

Code: Alles auswählen

# sed -i.BAK 's/BIG-REQUESTS/_IG-REQUESTS/' /usr/lib/x86_64-linux-gnu/libxcb.so.1.1.0

Kannst du direkt so als root ausführen. Wenn das dann nicht funktioniert, dann stellst du den alten Zustand wieder her mit:

Code: Alles auswählen

# mv /usr/lib/x86_64-linux-gnu/libxcb.so.1.1.0.BAK /usr/lib/x86_64-linux-gnu/libxcb.so.1.1.0

[frankw]

Der hack hab ich auch irgendwo gesehen...kann nur nicht funktionieren, da ich armhf und kein x86 system habe.

Ich habe noch lxterminal und in einer anderen vm den firefox 52 von ubuntu

[tobo]

Gut, dann halt so:

Code: Alles auswählen

sed -i.BAK 's/BIG-REQUESTS/_IG-REQUESTS/' /usr/lib/arm-linux-gnueabihf/libxcb.so.1.1.0
## und zurück mit:
mv /usr/lib/arm-linux-gnueabihf/libxcb.so.1.1.0.BAK /usr/lib/arm-linux-gnueabihf/libxcb.so.1.1.0

[frankw]

ändert leider nichts am Fehlerbild...es wurde aber was gemacht:

Code: Alles auswählen

# md5sum /usr/lib/arm-linux-gnueabihf/libxcb.so.1.1.0 
cd1590df36877a6a254bb3b3f39cf92d  /usr/lib/arm-linux-gnueabihf/libxcb.so.1.1.0
# md5sum /usr/lib/arm-linux-gnueabihf/libxcb.so.1.1.0.BAK 
05099edc6052590409bdbac49ae61175  /usr/lib/arm-linux-gnueabihf/libxcb.so.1.1.0.BAK

das blöde ist, dass chromium auch abschmiert...da steht aber irgendwas mit gpu da (welche ja im lxc-container nicht verfügbar ist)

[tobo]

Ja klar, es wurde ein "B" in einen "_" geändert, der Einstiegspunkt der Erweiterung praktisch aufgehoben. Ergo, mach das wieder rückgängig und hoffe auf weitere Antworten...

[frankw]

muss ja nicht heißen, dass der gesuchte String auch in der armhf-version vorhanden ist...habe aber das Backup wieder aktiviert

kann jemand etwas mit dem strace-dump anfangen?

Code: Alles auswählen

--- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=NULL} ---

sieht mir nach einem Segmentation Fault (Zugriffsverletzung) in zeile 3665 des Dumps aus, ich erkenne aber nicht, aus welchem Aufruf er resultiert

direkt davor kommt

Code: Alles auswählen

mprotect(0x2c52a000, 4096, PROT_READ|PROT_EXEC) = 0

ich habe hier noch die alten Pakete gefunden: http://snapshot.debian.org/binary/firefox-esr/ trotzdem sollte der Fehler behoben werden

[frankw]

Dieser bug-report sieht recht ähnlich aus...

https://bugs.debian.org/cgi-bin/bugrepo ... bug=919769

[hikaru]

Was heißt denn in deinem Fall "armhf-Architektur"? Was für ein SoC ist da verbaut und welche Flags hast du in /proc/cpuinfo?
Laut 908396 gab es mal ein Problem im Zusammenhang mit SSE2, was ja x86-Instruktionen sind. Rust (Worauf Firefox basiert) hatte in der Vergangenheit Probleme mit anderen Architekturen als x86 [1], meiner Wahrnehmung nach hauptsächlich deshalb, weil sich Rust Upstream für andere Architekturen nicht interessiert hat. Debian hat dann eher schlecht als Recht versucht, sich darum zu kümmern und war in dem Zuge auch gewillt, Rust Infrastruktur zur Verfügung zu stellen.
Ich war der Ansicht, dass sich daraufhin etwas bewegt hätte, habe das Thema aber seit einiger Zeit nicht mehr verfolgt. Es könnte also sein, dass das hier eine Auswirkung dieser Probleme ist.

Ich habe zu Hause ein Cubieboard 2 mit Allwinner A20 zu stehen. Darauf könnte ich mal versuchen, ob Firefox funktioniert. Ich meine, das mit Firefox 60 nach dessen Eintreffen in Stable schon mal erfolgreich probiert zu haben (auch via vnc), kann das mit der Versionsangabe aber gerade nicht beschwören.


[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1284816

[frankw]

der verlinkte Bug ist x86, ja, aber der raspi ist auch armhf, mein Gerät ist der Bananapi R2 (mt7623 als SOC)

Code: Alles auswählen

[09:29] frank@bpi-r2-e:~$ cat /proc/cpuinfo
processor	: 0
model name	: ARMv7 Processor rev 3 (v7l)
BogoMIPS	: 26.00
Features	: half thumb fastmult vfp edsp thumbee neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm 
CPU implementer	: 0x41
CPU architecture: 7
CPU variant	: 0x0
CPU part	: 0xc07
CPU revision	: 3

processor	: 1
model name	: ARMv7 Processor rev 3 (v7l)
BogoMIPS	: 26.00
Features	: half thumb fastmult vfp edsp thumbee neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm 
CPU implementer	: 0x41
CPU architecture: 7
CPU variant	: 0x0
CPU part	: 0xc07
CPU revision	: 3

processor	: 2
model name	: ARMv7 Processor rev 3 (v7l)
BogoMIPS	: 26.00
Features	: half thumb fastmult vfp edsp thumbee neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm 
CPU implementer	: 0x41
CPU architecture: 7
CPU variant	: 0x0
CPU part	: 0xc07
CPU revision	: 3

processor	: 3
model name	: ARMv7 Processor rev 3 (v7l)
BogoMIPS	: 26.00
Features	: half thumb fastmult vfp edsp thumbee neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm 
CPU implementer	: 0x41
CPU architecture: 7
CPU variant	: 0x0
CPU part	: 0xc07
CPU revision	: 3

Hardware	: Mediatek Cortex-A7 (Device Tree)
Revision	: 0000
Serial		: 0000000000000000

der Dump im Bug ist scheinbar mit gdb generiert...habe damit aber noch nichts gemacht...ich nehme an, dass ich dazu debug-symbols brauche (firefox-esr-dbg), oder sehe ich das falsch?

bei mir ist die Konstellation so, dass der firefox im vncserver (tightvnc) läuft welcher wiederum in einem Stretch-LXC-Container läuft. Es findet aber kein Architekturwandel mittels lxc statt, also sowohl host als auch container sind armhf.

wäre schön, wenn du das auf dem Cubieboard mal probieren könntest

[hikaru]

der Dump im Bug ist scheinbar mit gdb generiert...habe damit aber noch nichts gemacht...ich nehme an, dass ich dazu debug-symbols brauche (firefox-esr-dbg), oder sehe ich das falsch?

Im Prinzip ist das richtig. Ich weiß allerdings gerade nicht, welche dbg-Pakete du dafür brauchst. firefox-esr-dbg gibt es nicht mehr in Stable. Möglicherweise sind die Symbols nach firefox-esr gewandert oder werden gar nicht mehr von Debian angeboten.
Zusätzlich zu den Symbols des Pakets selbst sind möglichwerweise auch die seiner Abhängigkeiten hilfreich, je nachdem wo der Fehler auftritt. Welche Pakete du hier brauchst weiß ich nicht. In gdb wirst du das daran erkennen, dass du ohne passende Symbols an der Stelle nur einen kryptischen Backtrace kriegen wirst. libc6-dbg ist immer eine gute Idee.

bei mir ist die Konstellation so, dass der firefox im vncserver (tightvnc) läuft welcher wiederum in einem Stretch-LXC-Container läuft. Es findet aber kein Architekturwandel mittels lxc statt, also sowohl host als auch container sind armhf.

Abgesehen vom lxc-Container sollte ich das mit dem vorhandenen Setup noch heute Abend nachstellen können.
Wenn dein Container im Grunde nur ein chroot bereitstellt, dann sollte es hier abgesehen von Fehlkonfigurationen beim X-Forwarding keine Fehlerquellen geben. Kannst du andere GUI-Programme aus dem Container starten?

[frankw]

ich kann problemlos lxterminal starten und den alten firefox

[hikaru]

Ich kann das Problem auf dem CB2 mit frischem dist-upgrade reproduzieren. Direkt davor konnte ich es übrigens auch. Laut apt/history.log war das letzte dist-upgrade am 30.10.2018. Die Kiste war eine Weile nicht an. Firefox habe ich wohl damals nicht getestet.

Etwas Lyrik:

Code: Alles auswählen

$ cat /proc/cpuinfo 
processor	: 0
model name	: ARMv7 Processor rev 4 (v7l)
BogoMIPS	: 50.52
Features	: half thumb fastmult vfp edsp thumbee neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm 
CPU implementer	: 0x41
CPU architecture: 7
CPU variant	: 0x0
CPU part	: 0xc07
CPU revision	: 4

processor	: 1
model name	: ARMv7 Processor rev 4 (v7l)
BogoMIPS	: 50.52
Features	: half thumb fastmult vfp edsp thumbee neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm 
CPU implementer	: 0x41
CPU architecture: 7
CPU variant	: 0x0
CPU part	: 0xc07
CPU revision	: 4

Hardware	: Allwinner sun7i (A20) Family
Revision	: 0000
Serial		: 1651659004c161a2

Code: Alles auswählen

$ uname -a
Linux cubieboard2 4.9.0-8-armmp-lpae #1 SMP Debian 4.9.130-2 (2018-10-27) armv7l GNU/Linux

Code: Alles auswählen

$ cat /etc/debian_version 
9.7

Code: Alles auswählen

$ dpkg -l | grep firefox
ii  firefox-esr                           60.5.0esr-1~deb9u1                armhf        Mozilla Firefox web browser - Extended Support Release (ESR)
ii  firefox-esr-l10n-de                   60.5.0esr-1~deb9u1                all          German language package for Firefox ESR

strace sagt das: 40602
gdb: 40603

Aus den Outputs werde ich auf Anhieb nicht schlau. Zumindest kann man beiden entnehmen, dass das Problem offenbar in libxul.so liegt. Debug-Symbols dazu wären echt schick, gibt's leider nicht.
Der Test lief übrigens mit einem frischen Firefox-Profil. Vorher hat es Firefox teils noch geschafft, sein "We're Sorry!"-Fenster mit dem folgenden Text aufpoppen zu lassen:

Code: Alles auswählen

Firefox had a problem and crashed. We’ll try to restore your tabs and windows when it restarts.

To help us diagnose and fix the problem, you can send us a crash report.

Nach welchem System dieses Fenster kam oder auch nicht, habe ich nicht erkannt.

Ich würde mal vorsichtig andeuten, dass ich mich am Wochenende näher mit dem Problem beschäftigen werde, zumindest so weit um einen sinnvollen Bugreport abzusetzen, denn ich fände es mittelfristig schon schön, einen funktionierenden Firefox auf armhf zu haben. Ich verspreche aber nichts, denn im Moment bin ich eher in Faulenzerstimmung.

[hikaru]

Falls jemand eine Plattform hat, die weder x86 noch eine arm-Variante ist, wäre es schön, falls er darauf mal firefox-esr testen könnte.

[hikaru]

Ich habe noch ein paar Tests gemacht und kam zu dem Ergebnis, dass das Problem offenbar nur in Stretch auftritt. In einem Buster-chroot funktioniert Firefox problemlos.
Die Information habe ich in 919769 hinterlegt.

[frankw]

Danke dir schonmal...

dann wurde der bug in buster schon gefixt...evtl. gibt es von der libxul ein backport?

[hikaru]

libxul.so ist in firefox-esr enthalten und das Paket kommt aus dem Security-Repo. Das ist technisch schon ein Backport.

Zumindest scheint das Problem aber direkt aus diesem Paket zu kommen, nicht etwa aus einer Abhängigkeit, denn wenn man Firefox aus Stretch auf Buster installiert, stirbt der mit der selben Fehlermeldung.
Das Buster-Pakert auf Stretch zu installieren habe ich leider nicht geschafft. Die Abhängigkeiten sind auch mit Tricks nicht ohne Neucompilierung erfüllbar.

[frankw]

Das interessante ist,dass chromium auch abgestützt ist (hatte den nur als fallback versucht)...das aber scheinbar wegen fehlender gpu-unterstützung,oder greift das auch auf die fehlerhafte libxul zu?

[hikaru]

Das interessante ist,dass chromium auch abgestützt ist (hatte den nur als fallback versucht)...das aber scheinbar wegen fehlender gpu-unterstützung,oder greift das auch auf die fehlerhafte libxul zu?

Chromium sollte nicht auf libxul zugreifen. Um das umzusetzen müsste das Paket von firefox-esr abhängen, was aus diversen Gründen hässlich wäre.
Das Problem scheint aber schon früher aufzutreten. Offenbar fehlt unter armhf der dbus-Socket:

Code: Alles auswählen

$ chromium 
[5346:5512:0212/184007.797446:ERROR:bus.cc(394)] Failed to connect to the bus: Failed to connect to socket /run/user/1000/bus: Datei oder Verzeichnis nicht gefunden
Received signal 11 SEGV_MAPERR 000000000000
#0 0x000001d2cbf0 <unknown>
#1 0x000001cb9300 <unknown>
#2 0x000001d2cee2 <unknown>
#3 0x000001d2d124 <unknown>
#4 0x0000b2cbcfe0 <unknown>
#5 0x000000a61fe0 <unknown>
#6 0x000001faac94 <unknown>
#7 0x000002367916 <unknown>
#8 0x000002c5d6dc <unknown>
#9 0x000002c5d7a8 <unknown>
#10 0x000002c5d87c <unknown>
#11 0x000002c5d904 <unknown>
#12 0x000002c5d936 <unknown>
#13 0x000001c01c88 <unknown>
#14 0x000001c01cc2 <unknown>
#15 0x000001ab5cc0 <unknown>
#16 0x000001ab9d14 <unknown>
#17 0x000001ab9f82 <unknown>
#18 0x000000ef2ad6 <unknown>
#19 0x000001136836 <unknown>
#20 0x000000ef9182 <unknown>
#21 0x000000ef966a <unknown>
#22 0x000000ef4776 <unknown>
#23 0x000001a98e74 <unknown>
#24 0x000001a9969a <unknown>
#25 0x000001a9dffe <unknown>
#26 0x000001a98c78 <unknown>
#27 0x0000008e6190 ChromeMain
#28 0x0000b2cae4aa __libc_start_main
[end of stack trace]
Calling _exit(1). Core file will not be generated.
cubie@cubieboard2:~$ ATTENTION: default value of option force_s3tc_enable overridden by environment.
[5384:5384:0212/184011.020887:ERROR:sandbox_linux.cc(379)] InitializeSandbox() called with multiple threads in process gpu-process.
$ ls -l /run/user/1000/bus
ls: Zugriff auf '/run/user/1000/bus' nicht möglich: Datei oder Verzeichnis nicht gefunden

Warum das so ist, weiß ich nicht. Auf den ersten Blick scheinen mir die möglicherweise wichtigen dbus-Pakete installiert zu sein:

Code: Alles auswählen

$ dpkg -l | grep dbus
ii  at-spi2-core                          2.22.0-6+deb9u1                   armhf        Assistive Technology Service Provider Interface (dbus core)
ii  dbus                                  1.10.26-0+deb9u1                  armhf        simple interprocess messaging system (daemon and utilities)
ii  dbus-user-session                     1.10.26-0+deb9u1                  all          simple interprocess messaging system (systemd --user integration)
ii  dbus-x11                              1.10.26-0+deb9u1                  armhf        simple interprocess messaging system (X11 deps)
ii  libdbus-1-3:armhf                     1.10.26-0+deb9u1                  armhf        simple interprocess messaging system (library)
ii  libdbus-glib-1-2:armhf                0.108-2                           armhf        simple interprocess messaging system (GLib-based shared library)
ii  libqt5dbus5:armhf                     5.7.1+dfsg-3+deb9u1               armhf        Qt 5 D-Bus module
ii  libqtdbus4:armhf                      4:4.8.7+dfsg-11                   armhf        Qt 4 D-Bus module library

dbus-x11 hatte ich in Folge der Fehlermeldung nachinstalliert, aber das änderte nichts am Fehlerrbild.
Mit Chromium habe ich mich allerdings schon lange nicht mehr beschäftigt, weil ich dem Browser nicht vertraue.

firefox-esr hatte ich mir in der Zwischenzeit selbst gebaut. Dabei bekam ich u.a. auch firefox-esr-dbgsym, womit ich zu einer etwas aussagekräftigeren Fehlermeldung komme:

Code: Alles auswählen

$ gdb firefox-esr 
GNU gdb (Debian 7.12-6) 7.12.0.20161007-git
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "arm-linux-gnueabihf".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from firefox-esr...Reading symbols from /usr/lib/debug/.build-id/9a/3d1c7604e8fee7a83a3e9fb6bf69c59574e13d.debug...done.
done.
(gdb) run
Starting program: /usr/bin/firefox-esr 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/arm-linux-gnueabihf/libthread_db.so.1".
[New Thread 0xb146f450 (LWP 24523)]
[Thread 0xb146f450 (LWP 24523) exited]
[New Thread 0xb146f450 (LWP 24529)]
[New Thread 0xad8ff450 (LWP 24532)]
[New Thread 0xad0ff450 (LWP 24533)]
[New Thread 0xac8ff450 (LWP 24534)]
[New Thread 0xabfff450 (LWP 24535)]
[New Thread 0xab7ff450 (LWP 24536)]
[New Thread 0xab5ff450 (LWP 24537)]
[New Thread 0xaaeff450 (LWP 24538)]
[New Thread 0xaacff450 (LWP 24539)]
[New Thread 0xaaaff450 (LWP 24540)]
[New Thread 0xaa2ff450 (LWP 24541)]
[New Thread 0xa98ff450 (LWP 24542)]
[New Thread 0xa90ff450 (LWP 24544)]
[New Thread 0xa90df450 (LWP 24545)]

Thread 1 "firefox-esr" received signal SIGSEGV, Segmentation fault.
0xb3b6e272 in JS::MutableHandle<JS::Value>::set (v=..., this=<synthetic pointer>)
    at /root/debuild/ff/firefox-esr-60.5.0esr/build-browser/dist/include/js/RootingAPI.h:572
572	/root/debuild/ff/firefox-esr-60.5.0esr/build-browser/dist/include/js/RootingAPI.h: No such file or directory.
(gdb)

Den Paketbau habe ich in einem chroot auf dem Cubieboard gemacht, wobei /root/debuild/ff der Build-Pfad innerhalb des chroots war. Deuten kann ich die Fehlermeldung leider nicht.
/root/debuild/ff/firefox-esr-60.5.0esr/build-browser/dist/include/js/RootingAPI.h existiert und ist ein Symlink auf:
/root/debuild/ff/firefox-esr-60.5.0esr/js/public/RootingAPI.h [1]
Diese Link-Datei-Beziehung sieht in einer amd64-VM, wo ich ebenfalls Firefox gebaut hatte, übrigens nicht anders aus. Nur wird hier offenbar RootingAPI.h gefunden und der Firefox-Selbstbau startet problemlos.


[1] https://sources.debian.org/src/firefox- ... tingAPI.h/

[frankw]

Code: Alles auswählen

/root/debuild/ff/firefox-esr-60.5.0esr/build-browser/dist/include/js/RootingAPI.h:572

scheint mir eher die Zeilennummer 572 in der header-datei zu sein, dort ist ein Pointerzugriff () in der Methode set innerhalb der Klasse MOZ_STACK_CLASS MutableHandle

https://sources.debian.org/src/firefox- ... PI.h/#L572

ich weis jetzt natürlich nicht, was in dem Pointer drinsteht...der Fehlermeldung nach scheint es ein Dateiname zu sein...aber welcher, MutableHandle klingt mir nach einer Art Lock-Datei

wegen chromium, hatte den auch nur als Alternative installiert wo firefox nicht funktioniert hat...

[hikaru]

Code: Alles auswählen

/root/debuild/ff/firefox-esr-60.5.0esr/build-browser/dist/include/js/RootingAPI.h:572

scheint mir eher die Zeilennummer 572 in der header-datei zu sein, dort ist ein Pointerzugriff () in der Methode set innerhalb der Klasse MOZ_STACK_CLASS MutableHandle

https://sources.debian.org/src/firefox- ... PI.h/#L572

ich weis jetzt natürlich nicht, was in dem Pointer drinsteht...der Fehlermeldung nach scheint es ein Dateiname zu sein...aber welcher, MutableHandle klingt mir nach einer Art Lock-Datei

Ich hatte genau das versucht rauszufinden, indem ich den gdb-Aufruf nochmal durch strace geschickt hatte. Dabei entstand ein über 200MB großes Log in dem sich leider keiner meiner Suchbegriffe "RootingAPI", "572", "Mutable" finden ließ.

wegen chromium, hatte den auch nur als Alternative installiert wo firefox nicht funktioniert hat...

Unter Buster funktioniert übrigens auch Chromium. Er wirft zwar auch dort die dbus-Meldung, das hält ihn aber nicht vom Starten ab.
Vielleicht machst du einfach schon ein dist-upgrade.