Discussion:
Firefox-esr crashed on ARMHF
Vasant K
2018-10-17 01:28:28 UTC
Permalink
Hi,

The latest Firefox-esr 60.2.2 crashed on my ARMHF Debian stretch.
The last working version was 52.9. Has anyone else seen this crash.
I am also wondering if Debian packages are actually tested on each of the
architectures they support.

Vasant
Robert Wilkinson
2018-10-17 10:51:02 UTC
Permalink
Post by Vasant K
Hi,
The latest Firefox-esr 60.2.2 crashed on my ARMHF Debian stretch.
Once or consistently?
Post by Vasant K
The last working version was 52.9. Has anyone else seen this crash.
Any details to help?

If the crash is consistent, did you run firefox under strace?
Post by Vasant K
I am also wondering if Debian packages are actually tested on each of the
architectures they support.
Yes.
Post by Vasant K
Vasant
R
--
Abandon the search for Truth; settle for a good fantasy.
John Paul Adrian Glaubitz
2018-10-17 11:04:19 UTC
Permalink
Post by Vasant K
I am also wondering if Debian packages are actually tested on each of the
architectures they support.
Yes.
Do we actually do that already? I mean, beyond the autopkg checks, piuparts
and the testsuite being run. I think what Debian is still missing is some
automated installation and application tests like openSUSE's OpenQA.

Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - ***@debian.org
`. `' Freie Universitaet Berlin - ***@physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Marc
2018-10-17 11:44:40 UTC
Permalink
Post by Robert Wilkinson
Post by Vasant K
The latest Firefox-esr 60.2.2 crashed on my ARMHF Debian stretch.
Once or consistently?
Post by Vasant K
The last working version was 52.9. Has anyone else seen this crash.
Any details to help?
See my message to this list on 9/12 2018 08:15:13 +0200, and my
similar message in bug #908396.

Unable to find any pointers about this problem for several weeks,
with lots of hints by Mozilla that they're unwilling to support
anything but x86-64, and without any supported browser left (Chromium
just segfaulted, and the rest is explicitly unsupported in Debian),
I actually switched back to amd64 because of this.

I've still got my old system around. If I can think of my old
password, I'll give the current firefox-esr package a whirl tonight.
(I left at 60.2.0.)
ibu ☉ radempa
2018-10-17 15:49:24 UTC
Permalink
Post by Marc
Post by Robert Wilkinson
Post by Vasant K
The latest Firefox-esr 60.2.2 crashed on my ARMHF Debian stretch.
Once or consistently?
Post by Vasant K
The last working version was 52.9. Has anyone else seen this crash.
Any details to help?
See my message to this list on 9/12 2018 08:15:13 +0200, and my
similar message in bug #908396.
There is also #909498, explicitly for armhf.
Post by Marc
Unable to find any pointers about this problem for several weeks,
with lots of hints by Mozilla that they're unwilling to support
anything but x86-64, and without any supported browser left (Chromium
just segfaulted, and the rest is explicitly unsupported in Debian),
I actually switched back to amd64 because of this.
I've still got my old system around. If I can think of my old
password, I'll give the current firefox-esr package a whirl tonight.
(I left at 60.2.0.)
I pulled 60.2.2esr-1 (and its dependencies) from unstable and it runs
stably since a few weeks (actually initially 60.2.1esr-1).

I also tried just upgrading the dependencies to the versions required by
60.2.2esr-1 from unstable and keeping 60.2.2esr-1~deb9u1 from stable,
but with that FF kept crashing.

What I find confusing: The changelogs of firefox-esr for stable and
unstable essentially contain the same items (since v52), but the one
reproducibly crashes, and the other reproducibly works. Given that I've
tried them in the same environment (versions of dependencies, kernel,
shell environment), they must be essentially different, or am I wrong?

Regards,
ibu
peter green
2018-10-17 19:59:52 UTC
Permalink
Post by ibu ☉ radempa
What I find confusing: The changelogs of firefox-esr for stable and
unstable essentially contain the same items (since v52), but the one
reproducibly crashes, and the other reproducibly works. Given that I've
tried them in the same environment (versions of dependencies, kernel,
shell environment), they must be essentially different, or am I wrong?
The most obvious suspect in that case would be toolchain issues, particularly the versions of rustc and llvm used to build the packages.
Loading...