FS#54515 - [firefox] Firefox stuck in infinite loop and doesn't start

Attached to Project: Arch Linux
Opened by Pekka Järvinen (raspi) - Monday, 19 June 2017, 18:49 GMT
Last edited by Jan Alexander Steffens (heftig) - Wednesday, 21 June 2017, 14:06 GMT
Task Type Bug Report
Category Packages: Extra
Status Closed
Assigned To Jan de Groot (JGC)
Jan Alexander Steffens (heftig)
Architecture x86_64
Severity High
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Description:
Firefox doesn't start from desktop nor CLI. Tried reinstalling firefox. LXQt as a desktop environment with minimal install.

Additional info:
Tested with virtual machine and physical machine. Same problem with both. Clean installs.

Steps to reproduce:
Try to start from desktop:
Firefox never starts after waiting hours or minutes.

Try to start from CLI:
% firefox

Blank line forever. Firefox doesn't start after waiting hours or minutes. CTRL-C to go back to shell.

Infinite loop:
--- SIGVTALRM {si_signo=SIGVTALRM, si_code=SI_TKILL, si_pid=5204, si_uid=1000} ---
rt_sigreturn({mask=[]}) = -1 EINTR (Interrupted system call)
wait4(5206, 0x7fff1aead1c4, 0, NULL) = ? ERESTARTSYS (To be restarted if SA_RESTART is set)
This task depends upon

Closed by  Jan Alexander Steffens (heftig)
Wednesday, 21 June 2017, 14:06 GMT
Reason for closing:  Works for me
Additional comments about closing:  Problem with proprietary graphics acceleration
Comment by patrick (potomac) - Tuesday, 20 June 2017, 00:23 GMT
did you use a new firefox profile ?

launch firefox like this in a console :

firefox -p

then create a new firefox profile
Comment by Pekka Järvinen (raspi) - Tuesday, 20 June 2017, 01:39 GMT
% strace firefox -p

....
recvmsg(28, {msg_namelen=0}, 0) = -1 EAGAIN (Resource temporarily unavailable)
recvmsg(28, {msg_namelen=0}, 0) = -1 EAGAIN (Resource temporarily unavailable)
read(3,

And nothing happens after that. Blank line forever without strace.
Comment by AK (Andreaskem) - Tuesday, 20 June 2017, 05:35 GMT
You are using a Finnish locale, right? Maybe try with en_US.UTF-8 or LC_ALL=C?
Comment by Pekka Järvinen (raspi) - Tuesday, 20 June 2017, 11:50 GMT
Yes. Using Finnish locale. Tried with both. No change. Also tried after installing packages firefox-i18n-fi and -en-us.
Comment by patrick (potomac) - Tuesday, 20 June 2017, 16:25 GMT
does the bug occur if you try to downgrade the firefox package to the 53 version ? ( previous versions are located in /var/cache/pacman/pkg, installation with pacman -U <name of the package> )

is it the first time you use firefox ?

check also if you have enough space disk in your /home and /tmp directories,
you may have more information about the crash by using "dmesg",

could it be also a CPU microcode problem if you managed to reproduce the bug inside a virtual machine, a CPU optmization flag during the compilation of firefox innapropriate for your CPU ?
Comment by Pekka Järvinen (raspi) - Tuesday, 20 June 2017, 19:13 GMT
Yes. It occurs with older version also.

I've used firefox since it was released in 2004 and GNU/Linux since 1998 but as a desktop just few years.

/tmp uses 4 KB / 4 GB
/ uses 23 GB / 100 GB

dmesg doesn't display any errors after running firefox.

Virtual machine is running on Windows 10 Pro x64 and VMware Workstation Player 12 with i7-3820.
Physical machine is old Intel Q6600.

firefox runs fine on Ubuntu, FreeBSD and Windows.

My guess is that arch {lxqt, xorg, firefox} minimal install doesn't install some needed libraries or maybe some directory or file permissions are wrong. There's several file/dir not found errors on that strace log. DBus, some unix socket or similar might also be the cause of the problem.

I think I last tested with working firefox maybe ~2-3 years ago on Arch.

And I think (I might remember incorrectly) I tested on Raspberry Pi 3 ~year ago with same problem. That uses RISC and not CISC so still my guess is towards missing files/perms/bus and not CPU related.
Comment by patrick (potomac) - Tuesday, 20 June 2017, 19:15 GMT
you can also test with the official binary from firefox's website :

https://www.mozilla.org/fr/firefox/new/

if the bug disapears with the official binary then it's probably a package problem from archlinux
Comment by AK (Andreaskem) - Wednesday, 21 June 2017, 08:21 GMT
Comparing your strace with one from my installation, I notice the following: Your last system call is
read(3, 0x7ffe989c1a70, 1023) = ? ERESTARTSYS (To be restarted if SA_RESTART is set)
For me, this is
read(3, "VENDOR\nVMware, Inc.\nRENDERER\nGal"..., 1023) = 107
which is a string from the graphics system that can be found in glxinfo, for example:

OpenGL vendor string: VMware, Inc.
OpenGL renderer string: Gallium 0.4 on llvmpipe (LLVM 4.0, 256 bits)
OpenGL core profile version string: 3.3 (Core Profile) Mesa 17.1.3

So what is the output of glxinfo on your virtual machine? Do you have direct rendering enabled? Graphics acceleration? OpenGL support?
Comment by Pekka Järvinen (raspi) - Wednesday, 21 June 2017, 13:45 GMT
Didn't work with Mozilla's own package.

% glxinfo
name of display: :0
*Hangs here until CTRL-C*

I also have this old bug still open (lxrandr finds NULL monitors) - https://sourceforge.net/p/lxde/bugs/858/

Workstation Player settings:
Display: Auto detect
[x] Accelerate 3D graphics
Use host setting

I just now tried with disabling "Accelerate 3D graphics" and FF starts!

Loading...