firefox stützt sofort ab
firefox stützt sofort ab
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
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
- Beiträge: 256
- Registriert: 08.08.2007 22:07:32
- Lizenz eigener Beiträge: MIT Lizenz
- Wohnort: 127.0.0.1
Re: firefox stützt sofort ab
Hi Frank,
starte mal mit strace...
starte mal mit strace...
Wenn deine Freunde Linux haben, wechsel zu Linux.
Wenn deine Freunde BSD haben, wechsel zu BSD.
Wenn deine Freunde Windows haben, wechsel deine Freunde.
Wenn deine Freunde BSD haben, wechsel zu BSD.
Wenn deine Freunde Windows haben, wechsel deine Freunde.
Re: firefox stützt sofort ab
habs mal in eine Log geschrieben und hier hochgeladen:
https://drive.google.com/open?id=13Ypji ... IH7hikW7ri
https://drive.google.com/open?id=13Ypji ... IH7hikW7ri
Re: firefox stützt sofort ab
Sicher doch. Zeige erstmal die Plaintext-Konsolenausgabe von:
Code: Alles auswählen
$ firefox --verbose
Re: firefox stützt sofort ab
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".
Re: firefox stützt sofort ab
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:
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
# sed -i.BAK 's/BIG-REQUESTS/_IG-REQUESTS/' /usr/lib/x86_64-linux-gnu/libxcb.so.1.1.0
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
Re: firefox stützt sofort ab
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
Ich habe noch lxterminal und in einer anderen vm den firefox 52 von ubuntu
Re: firefox stützt sofort ab
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
Re: firefox stützt sofort ab
ändert leider nichts am Fehlerbild...es wurde aber was gemacht:
das blöde ist, dass chromium auch abschmiert...da steht aber irgendwas mit gpu da (welche ja im lxc-container nicht verfügbar ist)
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
Re: firefox stützt sofort ab
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...
Re: firefox stützt sofort ab
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?
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
ich habe hier noch die alten Pakete gefunden: http://snapshot.debian.org/binary/firefox-esr/ trotzdem sollte der Fehler behoben werden
kann jemand etwas mit dem strace-dump anfangen?
Code: Alles auswählen
--- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=NULL} ---
direkt davor kommt
Code: Alles auswählen
mprotect(0x2c52a000, 4096, PROT_READ|PROT_EXEC) = 0
Re: firefox stützt sofort ab
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
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
Re: firefox stützt sofort ab
der verlinkte Bug ist x86, ja, aber der raspi ist auch armhf, mein Gerät ist der Bananapi R2 (mt7623 als SOC)
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
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
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
Re: firefox stützt sofort ab
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.frankw hat geschrieben:30.01.2019 09:34:47der 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?
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.
Abgesehen vom lxc-Container sollte ich das mit dem vorhandenen Setup noch heute Abend nachstellen können.frankw hat geschrieben:30.01.2019 09:34:47bei 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.
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?
Re: firefox stützt sofort ab
ich kann problemlos lxterminal starten und den alten firefox
Re: firefox stützt sofort ab
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:
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: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.
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
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.
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.
Re: firefox stützt sofort ab
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.
Re: firefox stützt sofort ab
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.
Die Information habe ich in 919769 hinterlegt.
Re: firefox stützt sofort ab
Danke dir schonmal...
dann wurde der bug in buster schon gefixt...evtl. gibt es von der libxul ein backport?
dann wurde der bug in buster schon gefixt...evtl. gibt es von der libxul ein backport?
Re: firefox stützt sofort ab
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.
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.
Re: firefox stützt sofort ab
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?
Re: firefox stützt sofort ab
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.frankw hat geschrieben:12.02.2019 12:53:09Das 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?
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
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
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)
/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/
Re: firefox stützt sofort ab
Code: Alles auswählen
/root/debuild/ff/firefox-esr-60.5.0esr/build-browser/dist/include/js/RootingAPI.h:572
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...
Re: firefox stützt sofort ab
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ß.frankw hat geschrieben:12.02.2019 19:51:13scheint 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 MutableHandleCode: Alles auswählen
/root/debuild/ff/firefox-esr-60.5.0esr/build-browser/dist/include/js/RootingAPI.h:572
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
Unter Buster funktioniert übrigens auch Chromium. Er wirft zwar auch dort die dbus-Meldung, das hält ihn aber nicht vom Starten ab.frankw hat geschrieben:12.02.2019 19:51:13wegen chromium, hatte den auch nur als Alternative installiert wo firefox nicht funktioniert hat...
Vielleicht machst du einfach schon ein dist-upgrade.