Firefox crashing constantly

abitoir · 2015-06-16 11:15:04

Firefox is up to some old tricks again. it's started crashing constantly and is unusable in the current state. After between 2 to 5 tabs are open, it will become completely unresponsive. If I move a desktop away and back in my window manager, the whole thing will be just a grey box. I usually kill it with "killall firefox"

Things I've tried to fix it:

+ New profile.
+ firefox -safe-mode
+ removing all extensions
+ restarting
+ pacman -S firefox to reinstall
+ running as root, sudo firefox

Nothing seems to fix it! Can you please help me get my browser back?

Last edited by abitoir (2015-06-16 11:16:03)

ayekat · 2015-06-16 12:13:55

I usually go for a clean start by removing (or at least temporarily renaming) the ~/.mozilla/firefox folder. But then again, I don't use it regularly...

Is there some output the moment it freezes? (pretty unlikely, though)
Does the CPU usage rise above average?
Is it site-specific, or will just visiting any random sites cause this?

Can you post the output of

pacman -Qi firefox

and

uname -a

?

abitoir wrote:

running as root, sudo firefox

Welcome to the Arch Linux forums!
While it is fine to try out various things for troubleshooting, some procedures may rather fall in the category "randomly doing stuff". Although firefox is probably trustworthy, in a general case, troubleshooting issues with an application by running it as root is a recipe for disaster in the long term.

abitoir · 2015-06-17 10:43:38

Is there some output the moment it freezes? (pretty unlikely, though)
No output I can see. Tried this in multiple window managers.

Does the CPU usage rise above average?
None more than normal, 5-20% cpu

Is it site-specific, or will just visiting any random sites cause this?
Any random site

pacman -Qi

Name           : firefox
Version        : 38.0.5-1
Description    : Standalone web browser from mozilla.org
Architecture   : x86_64
URL            : https://www.mozilla.org/firefox/
Licenses       : MPL  GPL  LGPL
Groups         : None
Provides       : None
Depends On     : gtk2  mozilla-common  libxt  startup-notification  mime-types  dbus-glib  alsa-lib  desktop-file-utils  hicolor-icon-theme  libvpx  icu  libevent  nss  hunspell  sqlite
Optional Deps  : networkmanager: Location detection via available WiFi networks [installed]
                 gst-plugins-good: h.264 video [installed]
                 gst-libav: h.264 video [installed]
                 upower: Battery API
Required By    : None
Optional For   : None
Conflicts With : None
Replaces       : None
Installed Size :  87.36 MiB
Packager       : Evangelos Foutras <evangelos@foutrelis.com>
Build Date     : Tue 02 Jun 2015 07:14:26 PM ICT
Install Date   : Tue 16 Jun 2015 11:38:43 AM ICT
Install Reason : Explicitly installed
Install Script : Yes
Validated By   : Signature

uname -a

Linux comp 4.0.5-1-ARCH #1 SMP PREEMPT Sat Jun 6 18:37:49 CEST 2015 x86_64 GNU/Linux

as for root, I tried that because someone suggested running as a different user.

I think this should technically be called a "hang" instead of a "crash" as the window stays open but is nonresponsive.

I've now tried:

Firefox refresh. New profile. Renaming the ~/.mozilla.firefox folder as you suggested.

Still dies, sometimes during startup.

ayekat · 2015-06-17 10:49:15

This seems fine... I'm a little out of ideas.

The moment firefox hangs, what is the output of

ps aux | grep firefox

?

Last edited by ayekat (2015-06-17 10:50:02)

abitoir · 2015-06-21 09:35:42

comp      1898 24.2  5.3 877356 212236 ?       Sl   16:34   0:11 firefox
comp      2078  0.0  0.0  24488  2688 pts/1    S+   16:35   0:00 grep --color=auto firefox

ayekat · 2015-06-21 12:16:52

You could try to attach gdb to the running/freezed firefox process:

$ gdb
<GNU copyright notice>
(gdb) attach 1898
<Attaching output>
(gdb) bt
<Stack output>

Note that I'm not very versed with gdb usage, but this way you should at least see at what point it is stuck - in my case (and probably in your case too, according to your `ps` output) it should be somewhere in `poll()` in /usr/lib/libc.so

In order to attach to a process, you'll first need to enable the permission to do so, as it is disabled in Arch Linux by default:

sudo sysctl kernel.yama.ptrace_scope=0

(otherwise you'll just get a `ptrace: Operation not permitted.` once you try to attach)

abitoir · 2015-06-24 07:13:26

Here's the gdb info:

(gdb) bt
#0  0x00007fb43f3d71f3 in epoll_wait () from /usr/lib/libc.so.6
#1  0x00007fb436ac34d8 in ?? () from /usr/lib/libevent-2.0.so.5
#2  0x00007fb436aae61a in event_base_loop () from /usr/lib/libevent-2.0.so.5
#3  0x00007fb43ce3ce76 in ?? () from /usr/lib/firefox/libxul.so
#4  0x00007fb43ce3e132 in ?? () from /usr/lib/firefox/libxul.so
#5  0x00007fb43ce3fe2b in ?? () from /usr/lib/firefox/libxul.so
#6  0x00007fb43ce3d1f7 in ?? () from /usr/lib/firefox/libxul.so
#7  0x00007fb43ff22354 in start_thread () from /usr/lib/libpthread.so.0
#8  0x00007fb43f3d6bfd in clone () from /usr/lib/libc.so.6
(gdb)

From the terminal running firefox (not sure if these are problematic errors?)

(process:24424): GLib-CRITICAL **: g_slice_set_config: assertion 'sys_page_size == 0' failed

(firefox:24424): Gtk-CRITICAL **: IA__gtk_clipboard_set_with_data: assertion 'targets != NULL' failed

(firefox:24424): Gtk-CRITICAL **: IA__gtk_clipboard_set_with_data: assertion 'targets != NULL' failed

(firefox:24424): Gtk-CRITICAL **: IA__gtk_clipboard_set_with_data: assertion 'targets != NULL' failed

ayekat · 2015-06-24 09:36:44

I... am out of ideas.

There's an event loop in a thread that blocks - but that's a pretty generic conclusion.
You could try to recompile firefox with debug symbols and debug it again, to see at what point in libxul/firefox the process gets stuck.

There is this Wiki article on how to compile a package with debug symbols (it involves either modifying /etc/makepkg.conf, or modifying the PKGBUILD - one apparently cannot just set a few environment variables temporarily).

Just a word of warning: compiling firefox takes a loooot of time, and I'm not very familiar with the internals of XUL, but I'm eager to help and learn
On the other hand, once there is a usable stack trace, things may hopefully get a little clearer.

EDIT
Just to rule things out, perhaps following the general system output with

journalctl -f

during the firefox freeze may also reveal some information (perhaps before you jump into recompiling firefox).

Last edited by ayekat (2015-06-24 09:38:56)

fabertawe · 2015-06-30 18:32:12

I fixed this by disabling the FIreTray extension. It appears (possibly, from what I can gather) to be an issue involving Firefox and GTK+ 2 and GTK+ 3 being loaded in the same address space. And involving libappindicator (apparently, from perusing FireTray bugs. Again, I'm guessing here.)

This only started for me when I built libappindicator-gtk2 and libappindicator-gtk3 when playing with kdeconnect (I don't use KDE or any DE for that matter though.)

hussam · 2015-08-12 20:31:33

I just ran into this (no extensions or plugins). I started a debug firefox build (gtk+ and libevent are already debug builds).
I'll file a bug report upstream when I have crash data and post the link here.

Last edited by hussam (2015-08-12 20:31:59)

Arch Linux

#1 2015-06-16 11:15:04

Firefox crashing constantly

#2 2015-06-16 12:13:55

Re: Firefox crashing constantly

#3 2015-06-17 10:43:38

Re: Firefox crashing constantly

#4 2015-06-17 10:49:15

Re: Firefox crashing constantly

#5 2015-06-21 09:35:42

Re: Firefox crashing constantly

#6 2015-06-21 12:16:52

Re: Firefox crashing constantly

#7 2015-06-24 07:13:26

Re: Firefox crashing constantly

#8 2015-06-24 09:36:44

Re: Firefox crashing constantly

#9 2015-06-30 18:32:12

Re: Firefox crashing constantly

#10 2015-08-12 20:31:33

Re: Firefox crashing constantly

Board footer