so the next update for thunderbird will carry this error?
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to firefox in Ubuntu.
https://bugs.launchpad.net/bugs/1711337
Title:
Firefox crashes at start on armv7L after 55.0.1 update
Status
still fails over and over again with 14.04 and 16.04!
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to firefox in Ubuntu.
https://bugs.launchpad.net/bugs/1711337
Title:
Firefox crashes at start on armv7L after 55.0.1 update
Status in M
With trusty 14.04 and chromium 65, it gives a few warning about 'Failed
to launch GPU process' and 'Lost UI shared context', but these are no
show stoppers, browser works fine. For the newer ubuntu versions I don't
know, the newer kernels don't work with this device.
Xenial and above got 66, are t
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
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
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to firefox in Ubuntu.
https://bu
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?
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to firefox in Ubuntu.
https://bugs.launchpad.net/bugs/17113
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 xe
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!
** Attachment added: "firefox-59.0.2-arm-gcc7.png"
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1711337/+attachment/5103738/+files/firefox-
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
** Bug watch added: Mozilla Bugzilla #1434526
https://bugzilla.mozilla.org/show_bug.cgi?
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
@jdonald: how can I direct the output of 'layout asm' from gdb into a
textfile?
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to firefox in Ubuntu.
https://bugs.launchpad.net/bugs/1711337
Title:
Firefox crashes at start on armv7L after
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.
--
You received this bug notification because you are a member of Desktop
Packages,
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...
/<>/firefox-59.0.1+build1/debian/gcc-mozilla/g++
0:08.90 checking whether the target C++ c
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 confirm
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 thi
I wrote an email to Chris Coulson, asking for some assistance with the
cflags. Hopefully he'll read it.
What you're saying about hardware requirements is not really true.
Firefox is pretty demanding in terms of memory, yes, but per job mostly.
On amd64 and if you build with gcc, it needs roughly 7
Hmm, why don't you poke the person who's responsible for the packaging
with this, to adjust the build script in a matter of passing different
cflags if using armv7 and trusty? I'm not really keen on setting up a
specific chroot for trusty, mostly because I have a limited internet
connection. The co
@Chituc #92 : don't think I can provide about:buildconfig from 57.x ,
because they segfault. 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.
On trusty, one can see the browser window maybe for 1/3 of a second or
so,
bug still not solved, got the update to firefox-59 on lubuntu-14.04
today, it still segfaults. So I spent a few hours to an install of arch
linux on my rpi2, simply because firefox never had this issue over
there, and it still doesn't hit this bug as of today.
arch linux is rolling release, atm th
Which is the bug id for the mentioned skia bug?
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to firefox in Ubuntu.
https://bugs.launchpad.net/bugs/1711337
Title:
Firefox crashes at start on armv7L after 55.0.1 update
Status in Mozilla
Thank you for your effort! Could you please attach a patch against the
firefox source tree for the changes you made, in regards to make it
compile with clang?
If you ran out of memory during linking of libxul.so you could try to
append '-Wl,--no-keep-memory -Wl,--reduce-memory-overheads' as ldflag
Sadly, this
>
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
<
doe
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!
--
You received this bug notification because you are a member of Desktop
Packages, which is su
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 solv
I just tested, bug is not fixed in 16.04 and not in 14.04.
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to firefox in Ubuntu.
https://bugs.launchpad.net/bugs/1711337
Title:
Firefox crashes at start on armv7L after 55.0.1 update
Status
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.
@moz
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.
-
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 th
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.
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to firefox
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?
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to firefox in Ubuntu.
https://bugs.launchpad.net/bugs/171
The crash, if you'd like to call it a crash, was about gpu hardware
acceleration. I tried to append --disable-gpu from console and this made
it go away plus the browser itself is much faster now in rendering. I
then disabled it permamently in the options.
The device is a nvidia tegra, the binary d
I managed to add enough swap space but unfortunatley it doesn't make any
difference, the trace is the same as printed without --debug in #8
My guess is that it is very similar problem to
https://bugs.launchpad.net/ubuntu/+source/chromium-browser/+bug/1563184
, but I don't get the segfault or any o
Well, I just installed the additonal dbgsym package for chromium and
started it with
chromium-browser --debug 2>&1 | tee gdb-chromium.txt
Apparently running out of memory, the device has only 433mb ram and an
additional 266mb as a swap on a SD card. However, I attached the small logfile
which
thank you for your effort of the upgrade to recent stable chromium-58
I am using it with the arm port of Ubuntu-14.04 on a ac 100 chromebook,
where I get something which seems to be a segmention fault while
starting the browser. This is the output from the console
Received signal 11 SEGV_MAPERR 0
34 matches
Mail list logo