There is a segmentation fault related to javascript, but without building a non-optimized version of firefox specifics are not available. Details below.
I tried to open firefox remotely from Jetson to my x86_64 host machine. Connected via “ssh -Y”, then ran firefox on command line. The purpose of this was to separate graphical display dependencies and desktop environment away from Jetson, and isolate behavior strictly to the runtime with everything graphical depending only on my desktop host machine (one which has everything set up and 100% tested for anything graphical).
I also get a hang if I start with the simple command line “firefox” (the shell front end pointed to by the symbolic link “/usr/bin/firefox” means you are really running “/usr/lib/firefox/firefox.sh”, which in turn opens “/usr/lib/firefox/firefox”). The issue shows as not being dependent upon the graphical environment, with a segmentation fault.
You can run “firefox --help” and see a number of options which firefox.sh can use in opening the binary file of “/usr/lib/firefox/firefox”. One of those options is “–debug” for starting firefox within gdb debugger. To make use of this you first need to install the debug symbols via:
sudo apt-get install firefox-dbg
The stack frame at failure is extremely large. At first I didn’t have actual firefox source code, I was disappointed to find that even with a stack frame I couldn’t see actual code in the backtrace. So further source code is required beyond the dbg package. The backtrace named “firefox_47.0+build3”, which I found here:
https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Source_Code/Downloading_Source_Archives
https://launchpad.net/ubuntu/+archive/primary/+files/firefox_47.0+build3.orig.tar.bz2
Once source is unpacked to “/build/firefox-lAZp76/firefox-47.0+build3” a useful backtrace can be presented, along with complete source code at each frame. Unfortunately, optimizing has stripped out actual values in the stack frame, so it isn’t possible to determine what arguments were actually passed without rebuilding firefox (optimizing needs to be removed). Build instructions are here for those interested:
https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Build_Instructions
The amount of RAM and other resources mean building a debug/non-optimized version on Jetson would need a lot of swap space and time, so I stopped at this point. Maybe someone else is more ambitious.
I’m wondering if anyone knows of any full 64-bit ARMv8-a/aarch64 platform actually runs firefox successfully? Does anyone know of any Linux 64-bit ARM environment on which firefox can be tested as run or fail?
Looking at strace there wasn’t a lot of useful information. Lots of FUTEX messages, perhaps this is really a threading issue.
Looking at ltrace things become more useful, but nothing conclusive. There may be some issues with threading which have a chance of being a bug of libraries and/or kernel, rather than from firefox. The tail of the failed ltrace:
strlen("nsSocketTransport") = 17
pthread_mutex_lock(0x7fb6100040, 18, 0, 0x3d74657372616863) = 0
pthread_mutex_unlock(0x7fb6100040, 32, 1, 0xfffff000) = 0
strncpy(0x7fb602a280, "nsSocketTransport", 17) = 0x7fb602a280
pthread_mutex_lock(0x7fb6100040, 56, 0, 0) = 0
pthread_mutex_unlock(0x7fb6100040, 64, 1, 0xfffc0000) = 0
pthread_mutex_lock(0x7fb6100040, 31, 0, 0x7ffc1ac004) = 0
pthread_mutex_unlock(0x7fb6100040, 32, 1, 0xffffc000) = 0
pthread_mutex_lock(0x7fb6100040, 32, 0, 0x7fb36b4a06) =
disable_breakpoint pid=8022, addr=0x55952f0d80: No such process
get_instruction_pointer: Couldn't read registers of 8022.
+++ killed by SIGILL +++
Apparently the instruction pointer corrupted or was otherwise invalid, possibly hitting at a thread context switch.