Firefox crashes at start on armv7L after 55.0.1 update

I have both an Odroid XU4 and crouton xenial (running on Asus C100) which are arm based and Firefox also does as described - Intel based machines that I have do not exhibit this issue

Status changed to 'Confirmed' because the bug affects multiple users.

I got the same problem on Raspberry Pi3 with Ubuntu Mate.

I run into this on 14.04 with armhf / arm device, it is an old ac100 netbook. Is there any kind of upstream bug at mozillas bugtracker?

I also got the same problem on Raspberry Pi3 with Ubuntu Mate 16.04 as soon as I did the first update.
https://ubuntu-mate.community/t/firefox-55-0-2-doesnt-start-crashes-on-ubuntu-mate-raspberrypi-3/14637 has some workarounds, if anybody thinks to look there.

This is probably an unhelpful post, but ff 55 works on arm64. So if you have a pi 3 and are desperate for the latest ff then *ubuntu arm64 is a possibility. Same machine crashes with lubuntu 16.04 armhf.

Same problem, Ubuntu MATE 16.04 on ASUS Chromebook Flip (C100P)

Same problem on ASUS Chromebook C201 running Xenial under Crouton (armhf).
firefox 55.0.1 and 55.0.2 (both published 8/17) crash immediately at launch.

firefox 52.0.2 from 8/15 still works for me:
https://launchpad.net/ubuntu/xenial/armhf/firefox/52.0.2+build1-0ubuntu0.16.04.1
firefox_52.0.2+build1-0ubuntu0.16.04.1_armhf.deb (40.4 MiB)

On the Mozilla bug people are saying they had 54 working, but there was no 53 or 54 on armhf in Ubuntu? That is why people are rolling back to 52 isn't it?

No, people go back to 52 because it is working and it is under active developement, hence gets sec. updates. firefox 53 and 54 branches are stalled, they are very likely vulnerable.

Not in Ubuntu. The link above is from March.

On a rpi2 I tested Arch Linux recently, and their firefox-55.0.2 binary does work like a charm. Which makes me wonder if this is a bug somewhere in the toolchain (they use bleeding edge very latest gcc/glibc/etc.), or if the culprit could be found with the configure options.

How can we find out the build/configure options the ubuntu team uses?

On the other hand, I tested a build with gentoo von armv7 and ran into a segfault with 55.0.2 as well.

Today I build firefox 56.0 beta 12 which segfaults as well (on gentoo-armv7a-unknown-hardfp)

The toolchain I built with is gcc-5.4.0, binutils-2.28.1, glibc-2.23

So I doubt this will solve itself :( and would like to opt for a downgrade of firefox to esr for as long as it takes to solve this.

This bug was fixed in the package firefox - 55.0.2+build1-0ubuntu4

---------------
firefox (55.0.2+build1-0ubuntu4) artful; urgency=medium

  * New usptream stable release (55.0.2build1)

  [ Rico Tzschichholz ]
  * Refresh patches
    - update debian/patches/revert-upstream-search-engine-changes.patch
  * Add multiple ppc64/arm/s390x build fixes
    - debian/patches/build-ppc64.patch
    - debian/patches/build-ppc64-s390x-curl.patch
    - debian/patches/build-ppc64-s390x-nss.patch
    - debian/patches/build-ppc64-s390x-rust.patch
  * Fix Spidermonkey build with no jit backend
    - debian/patches/fix-no-jit-backend.patch
  * Do not use compile-time page size for PowerPC
    - debian/patches/ppc-no-static-sizes.patch
  * Update debian/build/create-tarball.py to create xz-tarballs
  * Refresh patches
    - update debian/patches/ubuntu-search-defaults.patch
    - update debian/patches/ubuntu-ua-string-changes.patch
    - update debian/patches/unity-menubar.patch
    - update debian/patches/revert-upstream-search-engine-changes.patch
    - update debian/patches/normalize-distribution-searchplugins.patch
  * Remove obsolete --enable-gio option
    - update debian/config/mozconfig.in
  * Refresh shipped locales
    - update debian/config/locales.shipped
    - update debian/control
  * Don't let debhelper clean Cargo.toml.orig files which are actually required

  [ Chris Coulson ]
  * Refresh patches
    - update debian/patches/unity-menubar.patch
  * Disable ALSA backend for Firefox 55 because it makes the build failure.
    This will remain disabled until somebody steps up to maintain it
  * Fix a build failure in cubeb-pulse-rs on architectures where char is
    unsigned
    - add debian/patches/cubeb-pulse-rs-fix.patch
    - update debian/patches/series
  * Refactor nsNativeMenuService ownership and shutdown behaviour - the only
    reference to it now is held by the service manager, and the global instance
    pointer is no longer cleared during the xpcom-shutdown notification. This
    fixes a shutdown UAF that appeared in the current Firefox version, where
    nsWindow and the associated nsMenuBar can be destroyed after xpcom-shutdown,
    when it was too late to clean up properly.
    - update debian/patches/unity-menubar.patch
  * Hopefully fix LP: #1711337 by building the armhf build with
    -fno-schedule-insns to work around a compiler bug
  * Backport a couple of upstream breakpad-client fixes to unbreak the build
    with glibc 2.26
    - add debian/patches/use-ucontext_t-in-breakpad-client.patch
    - add debian/patches/use-ucontext_t-in-breakpad-client_2.patch
    - update debian/patches/series

 -- Chris Coulson <email address hidden> Mon, 07 Aug 2017 11:43:19 +0100

Firefox (55.0.2+build1-0ubuntu0.16.04.1) still crashing / unable to open on my Asus Chromebook running crouton target lxde

That is because, as far as I understand it, this bug hasn't been resolved for any ubuntu version lower than artful (17.10), for reasons unexplained. It might be related to the release of 56.0 a day ago, so it is best to wait a few days and hopefully the fix will be backported to esr branches.

@mozilla team: do you happen to have an upstream gcc bug url, since this is a compiler bug?

Any idea when the bug will be fixed in 56?

Please, fix it on Ubuntu 16.04 (latest Release and latest Beta are KO) !

I just tested, bug is not fixed in 16.04 and not in 14.04.

This is not fixed in 17.04 either. Tried 55 which supposedly has the fix above, and 56.

Sorry that should of been 17.10 (artful ardvark)!

Tagged also affected releases based on comment #20 and comment #22.

57 on 17.10 does not work either.

Please change status back to "confirmed". The released fix did not work, as evidenced by the ongoing duplicate bug reports.

The latest package installs on 16.04.3 does not work either.
I only could get it working by installing the "firefox_57.0.1+build2-0ubuntu0.16.04.1_armhf.deb" package.
Anyone has got if there is any latest fixed version?

So "firefox_57.0.1+build2-0ubuntu0.16.04.1_armhf.deb" is working ?

Confirmed as still broken on Raspberry Pi3

Version: 57.0.1+build2-0ubuntu0.16.04.1

The fix was never ported into v56 or newer

That fix was:
> * Hopefully fix LP: #1711337 by building the armhf build with
> -fno-schedule-insns to work around a compiler bug
?

According to https://launchpadlibrarian.net/351233449/buildlog_ubuntu-xenial-armhf.firefox_57.0.3+build1-0ubuntu0.16.04.1_BUILDING.txt.gz it's building with:
> --enable-optimize=-g -O2 -fno-schedule-insns

So it looks like the fix was indeed ported, but given the word "hopefully", but was it ever confirmed?

Just like Adam Smith with version 55, arm64 appears to be fine. And just like herrtimson with version 55, even armv7 works on Arch Linux but still crashes on Debian/Ubuntu: https://www.raspberrypi.org/forums/viewtopic.php?f=63&t=150438&start=50

firefox 57.0.3+build1-0ubuntu0.17.10.1 still fails.

On 12/30/17, James Donald <email address hidden> wrote:
> That fix was:
>> * Hopefully fix LP: #1711337 by building the armhf build with
>> -fno-schedule-insns to work around a compiler bug
> ?
>
> According to
> https://launchpadlibrarian.net/351233449/buildlog_ubuntu-xenial-armhf.firefox_57.0.3+build1-0ubuntu0.16.04.1_BUILDING.txt.gz
> it's building with:
>> --enable-optimize=-g -O2 -fno-schedule-insns
>
> So it looks like the fix was indeed ported, but given the word
> "hopefully", but was it ever confirmed?
>
> Just like Adam Smith with version 55, arm64 appears to be fine. And just
> like herrtimson with version 55, even armv7 works on Arch Linux but
> still crashes on Debian/Ubuntu:
> https://www.raspberrypi.org/forums/viewtopic.php?f=63&t=150438&start=50
>
> --
> You received this bug notification because you are subscribed to a
> duplicate bug report (1733340).
> https://bugs.launchpad.net/bugs/1711337
>
> Title:
> Firefox crashes at start on armv7L after 55.0.1 update
>
> Status in Mozilla Firefox:
> Confirmed
> Status in firefox package in Ubuntu:
> Fix Released
>
> Bug description:
> Firefox always crashes when launched after the 55.0.1 update on an
> Orange Pi PC Plus (a single-board computer similar to a Raspberry Pi),
> even in safe mode.
>
> I did a fresh install of Armbian (a Ubuntu Xenial 16.04 re-spin for
> ARM single-board computer) on a similar board (Orange Pi Plus 2e),
> installed Firefox and experienced the same problem--it won't load
> without crashing.
>
> ProblemType: Bug
> DistroRelease: Ubuntu 16.04
> Package: firefox 55.0.1+build2-0ubuntu0.16.04.2
> Uname: Linux 3.4.113-sun8i armv7l
> AddonCompatCheckDisabled: False
> AlsaVersion: Advanced Linux Sound Architecture Driver Version 1.0.25.
> ApportVersion: 2.20.1-0ubuntu2.10
> Architecture: armhf
> AudioDevicesInUse:
> USER PID ACCESS COMMAND
> /dev/snd/controlC1: jim 1138 F.... pulseaudio
> /dev/snd/controlC0: jim 1138 F.... pulseaudio
> BuildID: 20170814194718
> Card0.Amixer.info:
> Card hw:0 'audiocodec'/'audiocodec'
> Mixer name : ''
> Components : ''
> Controls : 12
> Simple ctrls : 12
> Card1.Amixer.info:
> Card hw:1 'sndhdmi'/'sndhdmi'
> Mixer name : ''
> Components : ''
> Controls : 1
> Simple ctrls : 1
> Card1.Amixer.values:
> Simple mixer control 'hdmi audio format Function',0
> Capabilities: enum
> Items: 'null' 'pcm' 'AC3' 'MPEG1' 'MP3' 'MPEG2' 'AAC' 'DTS' 'ATRAC'
> 'ONE_BIT_AUDIO' 'DOLBY_DIGITAL_PLUS' 'DTS_HD' 'MAT' 'WMAPRO'
> Item0: 'pcm'
> Channel: Unavailable
> CurrentDesktop: XFCE
> Date: Thu Aug 17 05:37:00 2017
> Extensions: extensions.sqlite corrupt or missing
> ForcedLayersAccel: False
> IncompatibleExtensions: Unavailable (corrupt or non-existant
> compatibility.ini or extensions.sqlite)
> IpRoute:
> default via 192.168.10.1 dev eth0
> default via 192.168.10.1 dev wlan0 proto static metric 600
> 169.254.0.0/16 dev eth0 scope link metric 1000
> 192.168.10.0/24 dev eth0 proto kernel scope link src 1...

Not fixed for trusty, it still fails with the same error over and over again.

I do understand that this free software, and that the ubuntu devs are unpayed volunteers basically. However, this is one is a big bummer for so many people out there, so can you please throw some ressources at it to solve this eventually?

It is possible to solve it, see the arch linux binary.

I think this bug can be fixed, but the first step is getting someone with the required permissions to acknowledge that it exists, and change the status back to confirmed. With its current status, it probably isn't showing up on the radar of any Ubuntu developers.

Maybe someone could ping the team in the irc?

By the way, https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1732954 is a duplicate, but it has some additional information in terms of a backtrace!

firefox-57.0.4 still fails

cloudsto@RIKOMAGIC:~$ firefox -g
GNU gdb (Ubuntu 8.0.1-0ubuntu1) 8.0.1
Copyright (C) 2017 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 /usr/lib/firefox/firefox...Reading symbols from
/usr/lib/debug//usr/lib/firefox/firefox...done.
done.
(gdb) run
Starting program: /usr/lib/firefox/firefox
Cannot parse expression `.L1200 4@r4'.
warning: Probes-based dynamic linker interface failed.
Reverting to original interface.

[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/arm-linux-gnueabihf/libthread_db.so.1".
[New Thread 0xb17ff440 (LWP 15197)]
[New Thread 0xadf28440 (LWP 15198)]
[Thread 0xadf28440 (LWP 15198) exited]
[New Thread 0xadf28440 (LWP 15199)]
[New Thread 0xaccb3440 (LWP 15200)]
[New Thread 0xac4b3440 (LWP 15201)]
[New Thread 0xabaff440 (LWP 15202)]
[New Thread 0xab2ff440 (LWP 15203)]
[New Thread 0xab0ff440 (LWP 15204)]
[New Thread 0xaaeff440 (LWP 15205)]
[New Thread 0xaacff440 (LWP 15206)]
[New Thread 0xaaaff440 (LWP 15207)]
[New Thread 0xaa8ff440 (LWP 15208)]
[New Thread 0xaa6ff440 (LWP 15209)]
[New Thread 0xaa4ff440 (LWP 15210)]
[New Thread 0xa9dff440 (LWP 15215)]
[New Thread 0xa95ff440 (LWP 15216)]
[New Thread 0xa8dff440 (LWP 15217)]
[New Thread 0xa85ff440 (LWP 15218)]
[New Thread 0xa7cff440 (LWP 15219)]
[New Thread 0xb19d9440 (LWP 15221)]
[Thread 0xa7cff440 (LWP 15219) exited]
[New Thread 0xa7cff440 (LWP 15223)]
[New Thread 0xa6191440 (LWP 15224)]
[New Thread 0xa5724440 (LWP 15225)]
[New Thread 0xa4f24440 (LWP 15226)]
[New Thread 0xa4594440 (LWP 15229)]
[New Thread 0xa3d94440 (LWP 15230)]
[New Thread 0xa3594440 (LWP 15231)]
[New Thread 0xa2d94440 (LWP 15232)]
[New Thread 0xa23a9440 (LWP 15233)]
[New Thread 0xa1ba9440 (LWP 15234)]
[New Thread 0xa13a9440 (LWP 15235)]
[New Thread 0xa0ba9440 (LWP 15236)]
[Thread 0xa0ba9440 (LWP 15236) exited]
[Thread 0xa13a9440 (LWP 15235) exited]
[Thread 0xa1ba9440 (LWP 15234) exited]
[New Thread 0xa0ba9440 (LWP 15237)]
[New Thread 0xa13a9440 (LWP 15238)]
[New Thread 0xa1ba9440 (LWP 15239)]
[New Thread 0x9fa95440 (LWP 15240)]
[New Thread 0x9f295440 (LWP 15241)]
[New Thread 0x9ea95440 (LWP 15242)]
[New Thread 0x9e295440 (LWP 15243)]
[New Thread 0x9da95440 (LWP 15244)]
[New Thread 0x9d295440 (LWP 15245)]
[New Thread 0x9ca95440 (LWP 15246)]
[New Thread 0x9c0ff440 (LWP 15247)]
[New Thread 0x9b8ff440 (LWP 15248)]
[New Thread 0x9afff440 (LWP 15249)]
[New Thread 0x9a7ff440 (LWP 15250)]
[Thread 0x9c0ff440 (LWP 15247) exited]
[Thread 0x9b8ff440 (LWP 15248) exited]
[New Thread 0x999ff440 (LWP 15251)]
[New Thread 0x9...

This bug is not fixed properly

Thanks for providing the stack trace, Lars.

This shows the illegal instruction is happening in Skia, specifically SkJumper's implementation of _sk_xor__vfp4. To run with Skia disabled, edit your user profile at ~/.mozilla/firefox/*.default/prefs.js and add the following line:

user_pref("gfx.content.azure.backends", "");

Firefox 32-bit will then launch on Raspbian Stretch. Or if you have more than one user, you can instead edit /usr/lib/firefox/defaults/pref/vendor-gre.js

I expect rendering performance is taking a hit with Skia disabled. For a proper fix we should figure out what's going on with the illegal instruction(s) in SkJumper_generated.S. This file is auto-generated so from what I can tell the armv7 version isn't readily available via git. I have yet to set up a build environment for Firefox, but if someone here has done so for Arch Linux and another for Ubuntu, we can diff and track this down.

I have the same issue, however, I don't have the same stack trace.

$ firefox -g

(gdb) run
Starting program: /usr/lib/firefox/firefox

Program received signal SIGSEGV, Segmentation fault.
0xb6fd9dde in ?? () from /lib/ld-linux-armhf.so.3
(gdb) where
#0 0xb6fd9dde in ?? () from /lib/ld-linux-armhf.so.3
#1 0xb6fd9df6 in ?? () from /lib/ld-linux-armhf.so.3
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

# dpkg -l | grep firefox
ii firefox 57.0.4+build1-0ubuntu0.16.04.1 armhf Safe and easy web browser from Mozilla
ii firefox-dbg 57.0.4+build1-0ubuntu0.16.04.1 armhf Safe and easy web browser from Mozilla - debug symbols

Anyone knows how can I get a corrupt stack?

levente,

I'm not sure how Lars and Sam Tygier (#1732954) are getting useful backtraces. Might have something to do with running 17.10?

> ii firefox 57.0.4+build1-0ubuntu0.16.04.1 armhf

I see you're using 16.04. I should have mentioned that the workaround of disabling Skia is something I verified using the 14.04 Trusty package (on Raspbian). The flag also seems sufficient for Firefox to run on 17.10, but from what I can tell there's a second crash specific to the 16.04 build. To avoid that unknown, you can download and install the Trusty .deb (via dpkg -i) even if your system is 16.04 Xenial: https://launchpad.net/ubuntu/trusty/armhf/firefox/57.0.4+build1-0ubuntu0.14.04.1

This works with Ubuntu Mate 17.10 (armhf) on a Raspberry Pi 3

sudo apt-get purge firefox
wget http://launchpadlibrarian.net/352602073/firefox_57.0.4+build1-0ubuntu0.14.04.1_armhf.deb
sudo dpkg -i firefox_57.0.4+build1-0ubuntu0.14.04.1_armhf.deb
echo 'user_pref("gfx.content.azure.backends", "");' >> ~/.mozilla/firefox/*.default/prefs.js

Many thanks, James Donald.

there is one bug at mozilla about clang and arm, but it is more about android, I guess. Still: https://bug635044.bugzilla.mozilla.org/show_bug.cgi?id=1163171

Also freebsd builds with clang by default, they have a bug with a patch to fix it at their end for armv7, it might be possible to adapt this patch for ubuntu, if we want to switch over to build firefox with clang on arm.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=225279

This is the freebsd patch from their bug report. It was generated against their ports tree, I edited it so that it can be applied against the firefox source tree instead. This is not an official patch, and it fixes freebsd only, but still it might be helpfull to see what they changed. It is confirmed to build at their ends with clang for armv6 + armv7

adding this just in case it might be helpfull at some point

The attachment "firefox-esr-arm-clang-FREEBSD.patch" seems to be a patch. If it isn't, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are a member of the ~ubuntu-reviewers, unsubscribe the team.

[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issues please contact him.]

> [herrtimson] I wrote an email to Chris Coulson, asking for some assistance with the cflags. Hopefully he'll read it.

Thanks. I flagged him on #ubuntu-devel IRC as well. Hopefully we'll get his attention this time.

> > [Chituc] Can you check if the firefox 57.04 trusty , the working one shows
"-march=armv7-a -mfloat-abi=hard -mfpu=vfpv3-d16" in about:buildconfig ?
> [Chris] It’s not showing those flags in about:buildconfig

I don't think this matters, because Firefox 57 Trusty still has the Skia crash for most armhf users. The main difference between Firefox 57 and 58/59 is that in Firefox 57 it's possible to disable Skia via prefs.js, but otherwise the misaligned instruction bug is still there.

> it fixes freebsd only, but still it might be helpfull to see what they changed.

The majority of that patch deals with atomics, compare-and-swap, and memory barriers, although might be worth noticing that it does add -march=armv7-a

> [Chituc] Builing on xenial did nto worked but a build in trusty have great chances to work .

Right, but important to note that building on Bionic will likely work too. That point may be helpful in getting the Ubuntu team to prioritize.

> CFLAGS="-march=armv7-a -mfloat-abi=hard -mfpu=vfpv3-d16"

In case anyone is testing this soon, be sure to set both CFLAGS and CXXFLAGS. SkJumper_generated.S is assembly and I'm not sure which of the two flag sets gets passed, but the Skia project is largely C++.

CFLAGS="-march=armv7-a -mfloat-abi=hard -mfpu=vfpv3-d16" is the default for armhf. In fact, it's what *defines* armhf as armhf. Unless something is explicitly setting those things differently, they don't need to be on the commandline at all.

Ugh, yeah doing some simple helloworld tests confirms these are armhf gcc *defaults*.

> it's what *defines* armhf as armhf.

Defines: This appears true for -march=armv7-a -mfloat-abi=hard. As for -mfpu, adding -mfpu=neon results in some assembly differences, namely using register d16 and above.

> Unless something is explicitly setting those things differently

The Firefox build log has some instances of -mfpu=neon, particularly in Skia. However, Chromium does as well so indeed this is a longshot.

Looks like we're back to the drawing board. Still some hope with changes like building Skia using clang, adding -mthumb, or -fstack-protector-strong, but none of these other differences stand out as something present in both the Chromium and Arch Linux builds.

I think I misunderstood earlier about the intent of looking at Firefox 57's about:buildconfig. As that's technically still a Skia-broken build, we can continue to examine that configuration for other differences vs the Arch Linux one.

> [herrtimson] If there's a chance to get the output of about:buildconfig regardless the segfault at startup, I'm all eager to learn about this.

With broken browsers like Firefox 58 and 59 armhf, find the build config like so:

strings /usr/lib/firefox/omni.ja | grep -A 31 "Built from"

@Chituc,

I attempted to set up an Ubuntu 14.04 Firefox build environment, and am realizing how difficult it is to troubleshoot something old and barely supported.

Instead, could you take your existing 16.04 build flow but run sudo apt install g++-4.8 then build with CC=gcc-4.8, CXX=g++-4.8?

There's a decent chance this will get you past the strd r2, r3, [r1] crash, which would then allow you to complete your test of the clang Skia theory.

Ubuntu builds firefox for trusty with g++-4.9 , I checked this on amd64 some time ago and the build logs tell me that the armhf toolchain is as well g++-4.9

 0:08.79 checking for the target C++ compiler... /<<BUILDDIR>>/firefox-59.0.1+build1/debian/gcc-mozilla/g++
 0:08.90 checking whether the target C++ compiler can be used... yes
 0:08.90 checking the target C++ compiler version... 4.9.4
 0:08.98 checking the target C++ compiler works... yes
 0:08.98 checking for the host C compiler... /<<BUILDDIR>>/firefox-59.0.1+build1/debian/gcc-mozilla/gcc
 0:09.04 checking whether the host C compiler can be used... yes
 0:09.04 checking the host C compiler version... 4.9.4
 0:09.11 checking the host C compiler works... yes
 0:09.11 checking for the host C++ compiler... /<<BUILDDIR>>/firefox-59.0.1+build1/debian/gcc-mozilla/g++
 0:09.18 checking whether the host C++ compiler can be used... yes
 0:09.18 checking the host C++ compiler version... 4.9.4
 0:09.25 checking the host C++ compiler works... yes

If I use gcc-6.4.0 to compile with -g I get the same corrupt stack error as @levente before. Currently thinking about upgrading to gcc-7, as a last ressort, or waiting for bionic release in roughly a month or so.

@herrtimson we already confirmed that the gcc-7 / Bionic build crashes on the exact same misaligned instruction in Skia. See responses #48 and #50 for how I tested this, the point being that waiting for Bionic alone won't fix this.

Diagnosing a corrupt stack: whether you have debug symbols or not you should run this in gdb: layout asm. This will tell you if it's the same Skia illegal/misaligned instruction, the earlier SIGSEGV crash at strd r2, r3, [r1], or something else. Because levente was using a 16.04 deb he was most likely hitting the known SIGSEGV. Would be good to identify your build's crash because we don't have any other datapoints for gcc 6.

I thought it might be useful for you folks who have compiling experience to compare the compiler switches used in the Trusty build for 57.04 with those from Arch 59.0 (from post #90), so I've listed them in columns (attached), after I attempted to pull the switches out of @herrtmison's screenshot (might be a few errors from that though).

There are lots more switches in the Arch version... Perhaps a look at what's different may spark some ideas..

@jdonald: how can I direct the output of 'layout asm' from gdb into a textfile?

Thanks @Chris!

@herrtimson you can do this:
  layout asm
  tui disable
  set logging on
  disas /r <starting address>,<ending address>

It'll save the output of your disas command to gdb.txt

@levente (and maybe @herrtimson),

I set up a new Ubuntu MATE system, and in the process realized that your segfault in /lib/ld-linux-armhf.so.3 is a symptom of bug 1576432. That's where gdb fails not only for Firefox but even a simple helloworld program. The workaround there is to install libc6-dbg, which will allow you to see one of the other two crash signatures that we still don't have a solution for.

@Chituc,

By waiting a couple days on my Pi 3 I managed to make a gcc-4.9 build of Firefox 59.0.1, which then crashes on strd r2, r3, [r1]. I'm now thinking that this startup crash may be more nuanced than being specific to Ubuntu 16.04 or gcc-5.4. In fact, the Launchpad builds are now showing something odd: While the 59.0.1 14.04 build that we've talked about gets all the way to the Skia SIGILL, the recent 59.0.2 14.04 build from https://launchpad.net/ubuntu/trusty/armhf/firefox/59.0.2+build1-0ubuntu0.14.04.1 segfaults on the strd too.

At least with a custom build I'm now able to get accurate debug symbols. With the TUI I inspected the source at each level of this stack trace:

#0 0x717c4bc8 in JS::Value::setObjectNoCheck (obj=0x67d62160, this=<optimized out>) at /home/jdonald/firefox-59.0.1+build1/obj-arm-linux-gnueabihf/dist/include/js/Value.h:380
#1 JS::Value::setObject (obj=..., this=<optimized out>) at /home/jdonald/firefox-59.0.1+build1/obj-arm-linux-gnueabihf/dist/include/js/Value.h:375
#2 js::MutableWrappedPtrOperations<JS::Value, JS::MutableHandle<JS::Value> >::setObject (obj=..., this=<synthetic pointer>)
    at /home/jdonald/firefox-59.0.1+build1/obj-arm-linux-gnueabihf/dist/include/js/Value.h:1362
#3 mozJSComponentLoader::Import (this=this@entry=0x67a08000, registryLocation=..., targetValArg=..., targetValArg@entry=..., cx=cx@entry=0x76a56000,
    optionalArgc=optionalArgc@entry=0 '\000', retval=retval@entry=...) at /home/jdonald/firefox-59.0.1+build1/js/xpconnect/loader/mozJSComponentLoader.cpp:980
#4 0x717e8c64 in nsXPCComponents_Utils::Import (this=<optimized out>, registryLocation=..., targetObj=..., cx=0x76a56000, optionalArgc=0 '\000', retval=...)
    at /home/jdonald/firefox-59.0.1+build1/js/xpconnect/src/XPCComponents.cpp:2297
#5 0x7119c544 in NS_InvokeByIndex (that=0x1, methodIndex=0, paramCount=1742086496, params=0x7effb9f8)
    at /home/jdonald/firefox-59.0.1+build1/xpcom/reflect/xptcall/md/unix/xptcinvoke_arm.cpp:413
#6 0x0000001e in ?? ()

(and ran disas /r 0x717c4bc8,... to confirm that this symbol-laden debug session was still hitting strd r2, r3, [r1])

The most suspicious code is actually the XPCOM invocation. The armhf-specific assembly in https://hg.mozilla.org/mozilla-central/raw-file/tip/xpcom/reflect/xptcall/md/unix/xptcinvoke_arm.cpp is worrisome. It has no way of knowing whether registers d16 through d31 are available, so may allocate the wrong amount of stack space and clobber extra registers when mixing -mfpu=vfpv3-d16 with -mfpu=neon. The code in xptcinvoke_aarch64.cpp is completely different and looks more robust.

Thus, if anyone is trying to set up a build environment on Ubuntu 14.04 Trusty, keep in mind you might still hit the strd r2, r3, [r1] SIGSEGV. On Bionic: the 59.0.1 18.04 build fr...

The fix from 59.0.1 to 59.0.2 is literally two lines, it shouldn't be a problem.

Thank you for all of your effort, what you write about the messy assembler code seems reasonable. The more I read through the comments in that file, the more I wonder how this could ever worked out in the past.

There is a github read-only mirror of firefox code, it has history function to track down change of files and whole folders much easier, in case you need more evidence: https://github.com/mozilla/gecko-dev/tree/master/xpcom/reflect/xptcall/md/unix/

I'm now going to install glibc debug symbols, to see if the debugger is broken.

Here is a working Firefox 59 deb package cross-compiled for 18.04 armhf: https://www.dropbox.com/s/17ypog6btdq4wj7/firefox_59.0.1%2Bbuild1-0ubuntu1_armhf.deb?dl=0

I have installed and tested on RaspEX (Bionic armhf). I can also confirm it works sandboxed on Ubuntu MATE Xenial and Raspbian Stretch. One way to run on older systems is to unpack locally using ar + tar, download libc6 and libstdc++6 bionic armhf debfiles and untar them as well, then do:

  cd path/to/usr/lib/firefox
  LD_PRELOAD=path/to/usr/lib/arm-linux-gnueabihf/libstdc++.so.6:path/to/lib/arm-linux-gnueabihf/libm.so.6 \
    ./firefox

Cross-compiling via dpkg-buildpackage is fraught of issues, and similar to what Chituc experienced the most difficult part was getting rustc to properly cross-compile in all cases. I posted my main workaround for a host/target header bug here: https://github.com/rust-lang-nursery/rust-bindgen/issues/1229

To prevent the Skia misaligned instruction crash, I ended up editing gfx/skia/generate_mozbuild.py to force SK_JUMPER_USE_ASSEMBLY to False. However, there's stubborn code at the top of SkJumper.cpp that ends up turning it on again so I had to override that too. Telling Skia to use its non-asm fallback mode should be better than disabling Skia altogether as we had for Firefox 57.

I tested some of our earlier theories too, and so far building Skia with clang, everything with -thumb, -fstack-protector-strong, --enable-rust-simd or other suggestions above do not seem to help at all with the Skia SIGILL nor the strd r2, r3, [r1] SIGSEGV.

As for that strd r2, r3, [r1] crash, not much progress there aside from our theory that it's in the XPCOM armhf-specific code. I'm merely avoiding it by building in a 18.04 Docker container, but still no idea why that works.

Great , thank you ! I have a special build of skia dir I will try this into your build and see if it will work with skia asm anabled . Thanks again for hard work !

This patch should make it work! I was more lucky than anything else, because there is a compile error with firefox-60.0 betas on armhf which made me find https://bugzilla.mozilla.org/show_bug.cgi?id=1434526

toolchain used is:

glibc-2.25, binutils-2.29.1, gcc-7.3.0
rust-1.24.1, cargo 0.25.0, and llvm/clang-5

please test this with trusty toolchain!

@herrtimson are you expecting revert-128661.patch to fix the strd r2, r3, [r1] startup segfault on xenial/trusty, the Skia assembly illegal instruction, or both?

The discussion in bug 1434526 indicates this patch is necessary on Firefox 60 to resolve an armhf build failure on the latest trunk, but that regression appears to be newer than both of the crash symptoms at hand here.

The patch unbreaks the compile of firefox-60 betas on armhf, but at the same time it fixes the startup segfault which I had with the toolchain pasted in #120 with stable firefox.

The skia thing could be another story, therefore it would be helpfull to test build this with a trusty toolchain, or xenial if this is affected as well.

My device where I have trusty installed on is a AC100, it has only 512mb ram, but even worse the sd card slot is broken. I can't attach any fast external usb drive for swap or additional temp. space. The only thing I could do is to copy the whole filesystem over and use my rpi2 instead of, to build a deb package. It is just that I don't have much compile time left to spent on this at the moment, plus I'll first have to learn how to do this the debianish way. So if there is anyone who can build a deb and is willing to test it, please go for it.

@herrtimson from my tests that patch does not resolve the strd r2, r3, [r1] crash on Xenial. However, I do believe it's entirely possible that it indirectly fixed the issue with your gcc-7 toolchain. I'm starting to wonder if this crash does not have a single cause but rather is a codepath that Firefox goes down if there is one of many possible failures in startup.

In addition to the Bionic build above, this weekend I got a Raspbian Stretch build working: https://www.dropbox.com/s/sdqwuda5eaw0cks/firefox_59.0.2%2Bbuild1-stretch-rpi2_armhf.deb?dl=0 with some overview on the forums: https://www.raspberrypi.org/forums/viewtopic.php?f=63&t=150438

I used Bionic sources (deb-src http://ports.ubuntu.com/ubuntu-ports/ bionic main restricted) in a Stretch container (gcc-6). Initially it crashed on the same strd, so I tried switching to clang and then encountered the same "undefined reference to `free'" errors you guys had mentioned. These come about mainly due it not being supported to call free() before declaration in C99, so then the fix was to add #include <stdlib.h> in a couple places.

I don't think I'll attempt another Xenial or Trusty build anytime soon. I'd like to get some fixes documented and patches submitted upstream so that others can start building Firefox armhf across more platforms. Anyone can still run the 18.04 binary I linked earlier on 16.04 (and possibly 14.04) using the LD_PRELOAD trick.

As for how Arch Linux has been working, I've confirmed it's due to --disable-stylo (mentioned a while ago on the Raspberry Pi forum thread). If I add that flag (while leaving SK_JUMPER_USE_ASSEMBLY intact) then Firefox runs. For some reason the Stylo flag does not get listed in about:buildconfig but it's a very different build path when MOZ_STYLO is disabled, and Stylo is still disabled for Android nightly too.

@jdonald Wow (& sound a hats being taken off).
That really moves the boat forward - well done!
I did wonder what it was that allowed arch to work, and had a hunch that it would be hiding in plain sight in their PKGBUILD file, if only I could understand it.
Thank you for all that work - & your upstream fix intentions!

@herrtimson

Here's a 14.04 Trusty build: https://www.dropbox.com/s/977vzb3mu8bf34z/firefox_59.0.2%2Bbuild1-0ubuntu0.14.04.4_armhf.deb?dl=0

I used the same approach with clang + gcc headers inside a Trusty (gcc-4.8) container. Initially I got errors about ::gets() and Stack Overflow sent me down some rabbit holes of attempting to use gcc-4.9 headers or libc++ armhf. Ultimately the workaround was to comment out the offending line in gcc headers, and also fix a constexpr bug in the <complex> header. These kinds of hacks are something one can be more comfortable doing inside a Docker container.

I don't have a 14.04 armhf setup but I did test this on Raspbian Stretch. Would be great if you could try it out on your system. Note initially it used up all my Pi's RAM so I had to add 1 GB of swap.

For others, here is a 16.04 Xenial build: https://www.dropbox.com/s/ogdut56m2i0k0t9/firefox_59.0.2%2Bbuild1-0ubuntu0.16.04.3_armhf.deb?dl=0

Ah, cool thing! Could you please post a split patch against the debian file, so that I can see what you have changed exactly and how?

With debian file I mean the xz file which has all the patches, build scripts and so on, it should be called firefox_59.0.2+build1-0ubuntu0.14.04.4.debian.tar.xz

Fine!!!!!!
I installed this to my new tinkerboard ubuntu 16.04, Armbian kernel 4.4.120.
Seems to work fine.

Best regards Lars Nyqvist

On 5/4/18, James Donald <email address hidden> wrote:
> @herrtimson
>
> Here's a 14.04 Trusty build:
> https://www.dropbox.com/s/977vzb3mu8bf34z/firefox_59.0.2%2Bbuild1-0ubuntu0.14.04.4_armhf.deb?dl=0
>
> I used the same approach with clang + gcc headers inside a Trusty
> (gcc-4.8) container. Initially I got errors about ::gets() and Stack
> Overflow sent me down some rabbit holes of attempting to use gcc-4.9
> headers or libc++ armhf. Ultimately the workaround was to comment out
> the offending line in gcc headers, and also fix a constexpr bug in the
> <complex> header. These kinds of hacks are something one can be more
> comfortable doing inside a Docker container.
>
> I don't have a 14.04 armhf setup but I did test this on Raspbian
> Stretch. Would be great if you could try it out on your system. Note
> initially it used up all my Pi's RAM so I had to add 1 GB of swap.
>
> For others, here is a 16.04 Xenial build:
> https://www.dropbox.com/s/ogdut56m2i0k0t9/firefox_59.0.2%2Bbuild1-0ubuntu0.16.04.3_armhf.deb?dl=0
>
> --
> You received this bug notification because you are subscribed to a
> duplicate bug report (1733340).
> https://bugs.launchpad.net/bugs/1711337
>
> Title:
> Firefox crashes at start on armv7L after 55.0.1 update
>
> Status in Mozilla Firefox:
> Expired
> Status in firefox package in Ubuntu:
> Confirmed
>
> Bug description:
> Firefox always crashes when launched after the 55.0.1 update on an
> Orange Pi PC Plus (a single-board computer similar to a Raspberry Pi),
> even in safe mode.
>
> I did a fresh install of Armbian (a Ubuntu Xenial 16.04 re-spin for
> ARM single-board computer) on a similar board (Orange Pi Plus 2e),
> installed Firefox and experienced the same problem--it won't load
> without crashing.
>
> ProblemType: Bug
> DistroRelease: Ubuntu 16.04
> Package: firefox 55.0.1+build2-0ubuntu0.16.04.2
> Uname: Linux 3.4.113-sun8i armv7l
> AddonCompatCheckDisabled: False
> AlsaVersion: Advanced Linux Sound Architecture Driver Version 1.0.25.
> ApportVersion: 2.20.1-0ubuntu2.10
> Architecture: armhf
> AudioDevicesInUse:
> USER PID ACCESS COMMAND
> /dev/snd/controlC1: jim 1138 F.... pulseaudio
> /dev/snd/controlC0: jim 1138 F.... pulseaudio
> BuildID: 20170814194718
> Card0.Amixer.info:
> Card hw:0 'audiocodec'/'audiocodec'
> Mixer name : ''
> Components : ''
> Controls : 12
> Simple ctrls : 12
> Card1.Amixer.info:
> Card hw:1 'sndhdmi'/'sndhdmi'
> Mixer name : ''
> Components : ''
> Controls : 1
> Simple ctrls : 1
> Card1.Amixer.values:
> Simple mixer control 'hdmi audio format Function',0
> Capabilities: enum
> Items: 'null' 'pcm' 'AC3' 'MPEG1' 'MP3' 'MPEG2' 'AAC' 'DTS' 'ATRAC'
> 'ONE_BIT_AUDIO' 'DOLBY_DIGITAL_PLUS' 'DTS_HD' 'MAT' 'WMAPRO'
> Item0: 'pcm'
> Channel: Unavailable
> CurrentDesktop: XFCE
> Date: Thu Aug 17 05:37:00 2017
> Extensions: extensions.sqlite corrupt or missing
> ForcedLayersAccel: False
> Incompa...

@herrtimson I looked in the tarball and don't even see mention of my use of clang in mozconfig.

Note I'm using a procedure similar to what Chituc outlined. If I kick off dpkg-buildpackage, interrupt it, then edit the generated backend.mk I would not expect that to appear in patch files. It's also possible that due to use of the -b flag it skips version control comparisons, so the C++ source diffs are not appearing either.

For now I have documented pieces manually in this repo: https://github.com/jdonald/firefox-armhf

I'll update that repo as more steps come to mind. firefox_59.0.2.build1-0ubuntu0.14.04.4.debian.tar.xz is available for download there in the releases tab if you'd like to take a look through it.

Hi Donald,
I am writing this e-mail using your new
firefox_59.0.2+build1-0ubuntu0.14.04.4_armhf.deb version on a
TinkerOS, Debian GNU/Linux 9.4 (stretch) , kernel 4.4.71+
I started firefox in Downloads folder from terminal and got the following lines:
linaro@tinkerboard:~/Downloads$ firefox
[fresh] [error] probe_ppp_module, can't find libppGoogleNaClPluginChrome.so
[fresh] [error] probe_ppp_module, can't find libppGoogleNaClPluginChrome.so
[fresh] [error] probe_ppp_module, can't find libppGoogleNaClPluginChrome.so
[fresh] [error] probe_ppp_module, can't find libppGoogleNaClPluginChrome.so
[fresh] [error] probe_ppp_module, can't find libppGoogleNaClPluginChrome.so
[fresh] [error] probe_ppp_module, can't find libppGoogleNaClPluginChrome.so

Best regards and than you again Lars Nyqvist

On 5/5/18, James Donald <email address hidden> wrote:
> @herrtimson I looked in the tarball and don't even see mention of my use
> of clang in mozconfig.
>
> Note I'm using a procedure similar to what Chituc outlined. If I kick
> off dpkg-buildpackage, interrupt it, then edit the generated backend.mk
> I would not expect that to appear in patch files. It's also possible
> that due to use of the -b flag it skips version control comparisons, so
> the C++ source diffs are not appearing either.
>
> For now I have documented pieces manually in this repo:
> https://github.com/jdonald/firefox-armhf
>
> I'll update that repo as more steps come to mind.
> firefox_59.0.2.build1-0ubuntu0.14.04.4.debian.tar.xz is available for
> download there in the releases tab if you'd like to take a look through
> it.
>
> --
> You received this bug notification because you are subscribed to a
> duplicate bug report (1733340).
> https://bugs.launchpad.net/bugs/1711337
>
> Title:
> Firefox crashes at start on armv7L after 55.0.1 update
>
> Status in Mozilla Firefox:
> Expired
> Status in firefox package in Ubuntu:
> Confirmed
>
> Bug description:
> Firefox always crashes when launched after the 55.0.1 update on an
> Orange Pi PC Plus (a single-board computer similar to a Raspberry Pi),
> even in safe mode.
>
> I did a fresh install of Armbian (a Ubuntu Xenial 16.04 re-spin for
> ARM single-board computer) on a similar board (Orange Pi Plus 2e),
> installed Firefox and experienced the same problem--it won't load
> without crashing.
>
> ProblemType: Bug
> DistroRelease: Ubuntu 16.04
> Package: firefox 55.0.1+build2-0ubuntu0.16.04.2
> Uname: Linux 3.4.113-sun8i armv7l
> AddonCompatCheckDisabled: False
> AlsaVersion: Advanced Linux Sound Architecture Driver Version 1.0.25.
> ApportVersion: 2.20.1-0ubuntu2.10
> Architecture: armhf
> AudioDevicesInUse:
> USER PID ACCESS COMMAND
> /dev/snd/controlC1: jim 1138 F.... pulseaudio
> /dev/snd/controlC0: jim 1138 F.... pulseaudio
> BuildID: 20170814194718
> Card0.Amixer.info:
> Card hw:0 'audiocodec'/'audiocodec'
> Mixer name : ''
> Components : ''
> Controls : 12
> Simple ctrls : 12
> Card1.Amixer.info:
> Card hw:1 'sndhdmi'/'sndhdmi'
> Mixer name : ''
> Components : ''
> Controls : 1
> Simple ctrls : 1
> Card1.A...

Well, for me it doesn't really work. Downloaded this deb file from the github repo: firefox_59.0.2.build1-0ubuntu0.14.04.4_armhf.deb , installed it with dpkg -i , and got the error of 'ungültiger maschienenbefehl', which I am not sure what it does mean at all. Could be illegal assembler instruction.

Oh, and how do I revert this to the ubuntu one? *_*

Lars, I went to sites like Gmail or Youtube that I thought had a chance of using optional NaCl, but I haven't been able to reproduce those error messages. I don't think Firefox supports NaCl, even with a plugin. Is it possible you imported browser settings from Chromium and it happened to include their NaCl extension? You could rule this out by moving or deleting ~/.mozilla/firefox then trying again.

herrtimson, an illegal instruction would indicate your system lacks NEON or ARMv7 altogether, the same reason Firefox does not run on ARMv6 boards like Raspberry Pi B+ or Pi Zero. To check, cat /proc/cpuinfo

There's also a chance that ungültiger maschienenbefehl means bad interpreter or not in executable format / File format not recognized. You can troubleshoot this with the ldd and file commands. Compare properties of /usr/lib/firefox/firefox to any working command under /usr/bin

> Oh, and how do I revert this to the ubuntu one? *_*

sudo apt-get purge firefox
sudo apt-get install firefox

James,
Sorry, I had to report that the bug appeared only when starting
Firefox the first time since then everything is ok.

Regards Lars

On 5/6/18, James Donald <email address hidden> wrote:
> Lars, I went to sites like Gmail or Youtube that I thought had a chance
> of using optional NaCl, but I haven't been able to reproduce those error
> messages. I don't think Firefox supports NaCl, even with a plugin. Is it
> possible you imported browser settings from Chromium and it happened to
> include their NaCl extension? You could rule this out by moving or
> deleting ~/.mozilla/firefox then trying again.
>
> herrtimson, an illegal instruction would indicate your system lacks NEON
> or ARMv7 altogether, the same reason Firefox does not run on ARMv6
> boards like Raspberry Pi B+ or Pi Zero. To check, cat /proc/cpuinfo
>
> There's also a chance that ungültiger maschienenbefehl means bad
> interpreter or not in executable format / File format not recognized.
> You can troubleshoot this with the ldd and file commands. Compare
> properties of /usr/lib/firefox/firefox to any working command under
> /usr/bin
>
>> Oh, and how do I revert this to the ubuntu one? *_*
>
> sudo apt-get purge firefox
> sudo apt-get install firefox
>
> --
> You received this bug notification because you are subscribed to a
> duplicate bug report (1733340).
> https://bugs.launchpad.net/bugs/1711337
>
> Title:
> Firefox crashes at start on armv7L after 55.0.1 update
>
> Status in Mozilla Firefox:
> Expired
> Status in firefox package in Ubuntu:
> Confirmed
>
> Bug description:
> Firefox always crashes when launched after the 55.0.1 update on an
> Orange Pi PC Plus (a single-board computer similar to a Raspberry Pi),
> even in safe mode.
>
> I did a fresh install of Armbian (a Ubuntu Xenial 16.04 re-spin for
> ARM single-board computer) on a similar board (Orange Pi Plus 2e),
> installed Firefox and experienced the same problem--it won't load
> without crashing.
>
> ProblemType: Bug
> DistroRelease: Ubuntu 16.04
> Package: firefox 55.0.1+build2-0ubuntu0.16.04.2
> Uname: Linux 3.4.113-sun8i armv7l
> AddonCompatCheckDisabled: False
> AlsaVersion: Advanced Linux Sound Architecture Driver Version 1.0.25.
> ApportVersion: 2.20.1-0ubuntu2.10
> Architecture: armhf
> AudioDevicesInUse:
> USER PID ACCESS COMMAND
> /dev/snd/controlC1: jim 1138 F.... pulseaudio
> /dev/snd/controlC0: jim 1138 F.... pulseaudio
> BuildID: 20170814194718
> Card0.Amixer.info:
> Card hw:0 'audiocodec'/'audiocodec'
> Mixer name : ''
> Components : ''
> Controls : 12
> Simple ctrls : 12
> Card1.Amixer.info:
> Card hw:1 'sndhdmi'/'sndhdmi'
> Mixer name : ''
> Components : ''
> Controls : 1
> Simple ctrls : 1
> Card1.Amixer.values:
> Simple mixer control 'hdmi audio format Function',0
> Capabilities: enum
> Items: 'null' 'pcm' 'AC3' 'MPEG1' 'MP3' 'MPEG2' 'AAC' 'DTS' 'ATRAC'
> 'ONE_BIT_AUDIO' 'DOLBY_DIGITAL_PLUS' 'DTS_HD' 'MAT' 'WMAPRO'
> Item0: 'pcm'
> Channel: Unavailable
> CurrentDesktop: XFCE
> Date: Thu Aug 17 05:37:00 2017
> Extensions: extension...

Hi James, I have tested your
firefox_59.0.2+build1-0ubuntu0.14.04.4_armhf.deb on a
Debian GNU/Linux 9.4 (stretch) and Rockmyy's
Linux tinkerboard 4.17.0-rc3-RockMyy-Seventeen

Any push to the Sound slider quiets sound permanently but the mute
button works ok when
looking a video from youtube.com, areena.yle.fi

Chromium (Version 63.0.3239.84 (Developer Build) built on Debian 9.3,
running on Debian 9.4 (32-bit)) has no problems with the slider.

I know that 4.17.0-rc3 is not supported yet but a problem may lay on the path.

Regards Lars

Hi everybody, Mozilla developer here, I've come across this after we noticed the crash spike on our servers. The relevant bug is here: https://bugzilla.mozilla.org/show_bug.cgi?id=1452128

Unfortunately the symbols for this package weren't uploaded to our servers so we don't have a useful stack trace to work on. If Firefox' packager could get in touch with us we could debug this together.

firefox 60.0+build2-0ubuntu1 is launching for me without crashing (on ubuntu-mate 18.04 on rasberrypi 2B). I have not made any other changes.

Firefox working too on armhf xubuntu 18.04! (Pi 3B)

Thanks Mathias and Donald (comments 39 & 40)
after update to v61, Firefox crashes when lunched
Now, It works for me after installing v 57.0.4
Thanks a lot again for your help

still fails over and over again with 14.04 and 16.04!

so the next update for thunderbird will carry this error?

From what I can tell the maintainers have no intention of spending time supporting Ubuntu 16.04 or older. Even when Xenial was the current LTS they weren't responding here, and now that 18.04 has been out for 5 month there's even less motivation to handle older distros.

Having built Firefox 59 from source I think I get some of the reasons why they'd consider this a heavy support task. It's hard to get gcc and Rust to play nice on old cross-compiling toolchains, not to mention that sketchy assembly code for XPCOM. From a practical perspective, user workarounds can go in this order:

1) Use the latest firefox:armhf on 18.04 Bionic, if that's what you're running or you're open to upgrading.

2) Earlier distros like 16.04 or Debian Stretch: Install the latest firefox:arm64 if your system supports AArch64.

3) If armhf is the only option and you're on 16.04, you can still set up the firefox 18.04 deb package from Launchpad. Download its dependencies like libstdc++ and following my instructions in #117 to place the appropriate runtime-linked libraries.

Relying on armhf builds from Bionic in the worst case 3): this avoids having someone to maintain the whole build flow for Xenial and Trusty.

I'm only speaking for Firefox here, but if it all comes down to crashes in libxul.so then maybe much of this is sufficient for Thunderbird too.