[Bug 1711337] Re: Firefox crashes at start on armv7L after 55.0.1 update

[James Donald]

@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 at entry=0x67a08000, registryLocation=..., targetValArg=..., targetValArg at entry=..., cx=cx at entry=0x76a56000,
    optionalArgc=optionalArgc at entry=0 '\000', retval=retval at 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 from Launchpad was okay in this
regard, while the 59.0.2 18.04 build hasn't been posted yet so fingers
crossed that it does not regress in the same way.

-- 
You received this bug notification because you are a member of Mozilla
Bugs, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1711337

Title:
  Firefox crashes at start on armv7L after 55.0.1 update

To manage notifications about this bug go to:
https://bugs.launchpad.net/firefox/+bug/1711337/+subscriptions