Comment 115 for bug 1711337

@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 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.