Arch Linux

pgoetz

Member

From: Austin, Texas

Registered: 2014-02-21

Posts: 341

SOLVED: Firefox 63.0.2/63.0.3 unstable on Mate desktop

Since the last couple of updates Firefox has been completely unstable on my machine running the Mate desktop.  After some period of time (anywhere from 5 minutes to an hour) pages stop loading and the application stops responding to keyboard/mouse.  I do keep a lot of tabs/windows open, but the number is roughly constant, and I don't recall having had this problem before.  I tried refreshing Firefox (which recreates all the databases from scratch) and removed all Add-ons (I only had 2), but the problem persists.  I have plenty of RAM (32G), so don't think I'm running out of memory.  When I am able to quit the application after it becomes unstable and before I lose keyboard/mouse focus, the associated processes hang around for several minutes (e.g.

[pgoetz@frog ~]$ ps auxw | grep fire
pgoetz    9657 16.8  1.6 2624624 546916 ?      Sl   14:33   1:21 /usr/lib/firefox/firefox https://bbs.archlinux.org/viewtopic.php?pid=1820085#p1820085
pgoetz    9836  6.9  2.0 2198616 667392 ?      Sl   14:33   0:33 /usr/lib/firefox/firefox -contentproc -childID 3 -isForBrowser -prefsLen 83 -prefMapSize 169728 -schedulerPrefs 0001,2 -parentBuildID 20181116104104 -greomni /usr/lib/firefox/omni.ja -appomni /usr/lib/firefox/browser/omni.ja -appdir /usr/lib/firefox/browser 9657 true tab
pgoetz    9861  3.9  0.6 1768500 207820 ?      Sl   14:33   0:18 /usr/lib/firefox/firefox -contentproc -childID 4 -isForBrowser -prefsLen 83 -prefMapSize 169728 -schedulerPrefs 0001,2 -parentBuildID 20181116104104 -greomni /usr/lib/firefox/omni.ja -appomni /usr/lib/firefox/browser/omni.ja -appdir /usr/lib/firefox/browser 9657 true tab
pgoetz    9892 20.6  0.8 2115564 286960 ?      Sl   14:33   1:39 /usr/lib/firefox/firefox -contentproc -childID 5 -isForBrowser -prefsLen 83 -prefMapSize 169728 -schedulerPrefs 0001,2 -parentBuildID 20181116104104 -greomni /usr/lib/firefox/omni.ja -appomni /usr/lib/firefox/browser/omni.ja -appdir /usr/lib/firefox/browser 9657 true tab

and don't respond to pkill or kill -9.  Seems like some kind of newly introduced GTK3/Firefox bug.  Oddly enough, when this happens Thunderbird becomes unresponsive as well.  In fact, at first I thought this was a new Thunderbird bug and posted it as such before realizing that Thunderbird reverts to normal behavior as soon as all the Firefox processes have finally died.  Not sure I understand that one at all.

Last edited by pgoetz (2019-01-23 17:26:54)

pgoetz

Member

From: Austin, Texas

Registered: 2014-02-21

Posts: 341

Re: SOLVED: Firefox 63.0.2/63.0.3 unstable on Mate desktop

Some further experimentation revealed that Firefox 63.0.3 is completely stable on my system as long as a don't run Thunderbird 60.0.3 at the same time.  Thunderbird is stable as long as I don't start Firefox while Thunderbird is running.  It's just when I have them both open that everything starts to go haywire after sometimes barely 5-10 minutes of use.

paulkerry

Member

From: Sheffield, UK

Registered: 2014-10-02

Posts: 611

Re: SOLVED: Firefox 63.0.2/63.0.3 unstable on Mate desktop

Thunderbird 60.0.3 at the same time

Is this version number a typo?

pgoetz

Member

From: Austin, Texas

Registered: 2014-02-21

Posts: 341

Re: SOLVED: Firefox 63.0.2/63.0.3 unstable on Mate desktop

Cross posting from another problem ticket I filed on Thunderbird.  Posting this solution in case it helps anyone else who over-micromanaged their system the way I did.

I still don't understand the weirdness, but my problem, it turns out, had nothing to do with Thunderbird or Firefox.  A couple of years ago when I set the system up (using gummiboot, now systemd-boot I added the following boot options to the arch loader entry and then mostly forgot about it:

options root=/dev/md1 rw ipv6.disable=1

I figured that since I'm not using ipv6, why not disable it?  The tipoff that the problem was not application related was when someone else logged in to the machine after a fresh boot and

journalctl -b -p err

indicated that Xorg was crashing on boot:

-- Reboot --
Jan 22 19:38:07 frog kernel: [Firmware Bug]: TSC_DEADLINE disabled due to Errata; please update microcode to version: 0x22 (or later)
Jan 22 19:38:12 frog rpcbind[775]: cannot create socket for udp6
Jan 22 19:38:12 frog rpcbind[775]: cannot create socket for tcp6
Jan 22 19:38:12 frog rpc.mountd[755]: Could not make a socket: (97) Address family not supported by protocol
Jan 22 19:38:12 frog rpc.mountd[755]: Could not make a socket: (97) Address family not supported by protocol
Jan 22 19:38:12 frog rpc.mountd[755]: Could not make a socket: (97) Address family not supported by protocol
Jan 22 19:38:12 frog rpc.mountd[755]: Could not make a socket: (97) Address family not supported by protocol
Jan 22 19:38:12 frog rpc.statd[795]: Failed to create listener xprt (statd, 1, udp6)
Jan 22 19:38:12 frog rpc.mountd[755]: Could not make a socket: (97) Address family not supported by protocol
Jan 22 19:38:12 frog rpc.statd[795]: Failed to create listener xprt (statd, 1, tcp6)
Jan 22 19:38:12 frog rpc.mountd[755]: Could not make a socket: (97) Address family not supported by protocol
Jan 22 19:38:28 frog systemd-coredump[1131]: Process 1124 (Xorg) of user 0 dumped core.
                                             
                                             Stack trace of thread 1124:
                                             #0  0x00007f504d921d7f raise (libc.so.6)
                                             #1  0x00007f504d90c672 abort (libc.so.6)
                                             #2  0x0000561a2cc2daea OsAbort (Xorg)
                                             #3  0x0000561a2cc2455f FatalError (Xorg)
                                             #4  0x0000561a2cc3237e n/a (Xorg)
                                             #5  0x00007f504d921e00 __restore_rt (libc.so.6)
                                             #6  0x00007f504d921d7f raise (libc.so.6)
                                             #7  0x00007f504d90c672 abort (libc.so.6)
                                             #8  0x00007f504d90c548 __assert_fail_base.cold.0 (libc.so.6)
                                             #9  0x00007f504d91a396 __assert_fail (libc.so.6)
                                             #10 0x0000561a2ccdbf29 dixRegisterPrivateKey (Xorg)
                                             #11 0x00007f5046689ce9 glamor_init (libglamoregl.so)
                                             #12 0x00007f5049480f6d n/a (modesetting_drv.so)
                                             #13 0x0000561a2ccfd29d AddGPUScreen (Xorg)
                                             #14 0x0000561a2cbf9e5c n/a (Xorg)
                                             #15 0x0000561a2cbdc6d6 n/a (Xorg)
                                             #16 0x0000561a2cbcb1f9 n/a (Xorg)
                                             #17 0x0000561a2cbcb9a3 config_init (Xorg)
                                             #18 0x0000561a2cc120f7 InitInput (Xorg)
                                             #19 0x0000561a2cbb8734 n/a (Xorg)
                                             #20 0x00007f504d90e223 __libc_start_main (libc.so.6)
                                             #21 0x0000561a2cbb930e _start (Xorg)
                                             
                                             Stack trace of thread 1129:
                                             #0  0x00007f504cb58afc pthread_cond_wait@@GLIBC_2.3.2 (libpthread.so.0)
                                             #1  0x00007f5045d02c24 n/a (i965_dri.so)
                                             #2  0x00007f5045d02948 n/a (i965_dri.so)
                                             #3  0x00007f504cb52a9d start_thread (libpthread.so.0)
                                             #4  0x00007f504d9e5b23 __clone (libc.so.6)

This made it pretty clear that this had nothing to do with Thunderbird or Firefox.  Acting on hunch based on the rpc errors,  I removed ipv6.disable=1 which cleared up the on boot crashes, and I haven't had a problem since.