Firefox (Nightly) causing system crash

pfr

I can't be entirely sure of the cause of this, but this is what is what happened:

I was browsing the web (firefox) and then I installed iamb, the CLI Matrix client. Logged in, sent @pin a message or two, and a few mopments later the system froze up and rebooted. I thought, that's weird... but proceeded to log in and try again. I started firefox again and then opened a terminal and ran iamb once more, this time it froze up instantly and I had to hold the power button down to restart the system.

This time though, it did not boot correctly and while running filesystem checks it aborted. I can't get the original error to show again, but basically it said something like you need to run fsck_ffs MANUALLY and asked me to choose a shell, then kicked me into a root shell prompt. Here is what I was able to catch before it scrolled off screen:

Enter pathname of shell or RETURN for /bin/sh:
# fsck_ffs -n /
** /dev/rdk5 (NO WRITE)
** Last Mounted on /
** Root file system
** Phase 1 - Check Blocks and Sizes
INCORRECT BLOCK COUNT I=7355400 (8 should be 0)
CORRECT? no

91014209 DUP I=22440313
91028975 DUP I=22440315
91014209 DUP I=22440378
** Phase 1b - Rescan For More DUPS
91014209 DUP I=22440209
91028975 DUP I=22440298
** Phase 2 - Check Pathnames
DUP/BAD I=22440209 OWNER=1001 MODE=100644
SIZE=32 MTIME=Jun 17 13:08 2024
FILE=/home/dave/.mozilla/firefox/y74lurkd.default-default/storage/default/moz-extension***[....]^userContextID=[....].sqlite-wal

REMOVE? no

[...several more of these Firefox/moz-extension files...]

** Phase 5 - Check Cyl groups
BLK(S) MISSING IN BIT MAPS
SALVAGE? no

FREE BLK COUNT(S) WRONG IN SUPERBLK
SALVAGE? no

SUMMARY INFORMATION BAD
SALVAGE? no

612180 files, 3800882 used, 107449096 free (62568 frage, 13423316 blocks, 0.1% fragmentation)

***** UNRESOLVED INCONSISTENCIES REMAIN *****
#

From this I gather that iamb is not to blame here, but a firefox extension is...

Is there anything I can do to recover the system? It looks like I do not have access to write to the file system so simply removing those .mozilla/firefox files might not be possible.

This is very similar to what took me to a fresh install last week. In my case, the running applications were different, so I wouldn't draw any conclusions just yet.

Firefox doesn't like when X terminates while it is running, it always coredumps if you kill X.

If, the amount of incorrect blocks is small, it might be worthy to allow fsck a try.

As I've had issues like this one twice, I would like to get some information out of it. It would be good to identify the cause.

pfr

pin thank goodness, managed to salvage using fsck however in nervous to open Firefox again...

pfr however in nervous to open Firefox again...

As said, I think this was just a coincidence. Remove the Firefox core dumps (probably in your home folder) and you should be fine. I haven't seen a direct correlation between which program is running and the hard system freezes.

pfr

pin Well, I completely wiped firefox, removed the entire ~/.mozilla folder and reinstalled firefox. I signed in, all my extensions started automatically instlling again. It was stable for a while until I went to sign-in to the forum and tried to use the Bitwarden extension when it froze again. I can't 100% say that that particular extension is to blame, but It's suspect no.1 for now.

EDIT ok, it's just firefox itself. I seem to be fine when I dont sign-in to my ff account... can even add extensions.. but so far I'm being cautious.

Jay

pfr maybe try ArcticFox https://pkgsrc.se/www/arcticfox
I think creator of ArcticFox also uses NetBSD

kc9udx

Are you mounting / with journaling?

pfr

kc9udx I haven't set it intentionally, I would have assumed that this would be the default behaviour. How/where do I set this?

pfr How/where do I set this?

fstab, check the root partition line on it.
I have, /dev/wd0a / ffs rw,noatime,nodevmtime 1 1

If you want logging, add log to the comma separated list. In my case, it would be rw,noatime,nodevmtime,log.

OT, I have time stamps disabled to avoid excessive disk writes on my SSD.

pfr

I had to reinstall the system. The disk was cooked.

Jay Maybe ... articfoxdepends on x11/gtk2, though.

nia

pin I'm still convinced GTK 2 is the best X11 toolkit. GTK 3's ideologues chose to ignore 30 years of accumulated knowledge on how to design desktop applications, and the LXDE developer found it too unsuitable for developing lightweight X11 applications such that Qt is the better option. GIMP is the application GTK was made for and it's still a GTK 2 app. Qt has so many API/ABI compatibility and build slowness issues between releases that sticking with an unsupported toolkit often seems like the better option if you're compiling from source.

pfr

Yeah I dont think Arcticfox will cut it sadly.
But I have deduced that this issues is certainly related to Firefox on my machine, and it continues even after a fresh install.

I have added log to my fstab so I wonder where those logs are kept and what the say now after a few freeze-ups...

kc9udx

pfr I've never needed to investigate that. The whole idea behind journaling is that it prevents disk inconsistencies caused by crash-during-write by logging the writes and undoing the partial part, at mount time. This eliminates the need (normally) to fsck.

I much prefer atomic write (inherently safer and much faster) but journaling is what we get with FFS (and most others these days).

pfr

kc9udx I much prefer atomic write (inherently safer and much faster) but journaling is what we get with FFS (and most others these days).

Never heard of atomic... can you provide more details? And your saying it's not an option for FFS?

@pin I don't think starting a new thread is necessary, but perhaps if we could rename this one to "Firefox (Nightly) causing system crash)...

I wanted to continue this thread because the issue is not resolved, just avoided by not not signing in to my FF account.

The last time this freeze happened, was after I had freshly installed NetBSD once more. This time I wasn't even using FF when it froze. FF was open in another workspace, and I was signed in (perhaps it was still doing some kind of syncing in the background).

The error I saw upon reboot however was interesting because it referred to the same directory /home/dave/.mozilla/firefox/y74lurkd.default-default/storage/default/ but instead of an extension it refered to a web address file beginning with https// and the web address is a site I use (for accessing a vehicle registration account) but it's not even bookmarked and I hadn't visited it in a long while.... 😕

So, now I'm using FF without signing in and so far it has been stable, but WTF...

kc9udx

pfr atomic write causes a write to be not valid until it is complete. So if you were writing a 2Gb file and your system crashed, traditionally you end up with a partial file and bad metadata. With journaling, the changes can be "undone" and the filesystem will look like it did before the crash. With atomic write, the system is in the same state as it was before the crash because the write never happened.

The only trouble I'm aware of with atomic write is that you can effectively have less disk space. That is, if you are replacing a 2G file with a completely different 2G file, on a 3G partition, there isn't enough space to store the new data before deleting the old. In practice I've never encountered this but it's kind of dumb luck that I haven't.

I don't think any "modern" filesystem uses atomic write, because journaling is "good enough", and most people misunderstand atomic write. (My best example of this is the assumption that appending a file necessitates a complete separate copy of the original file. It does not.). Also, I think by now the concept of atomic write has been totally forgotten by anyone concerned with filesystems.

pfr

kc9udx Thanks for the explaination, makes sense now.

My only remaining question then is, why is journaling not enabled by default? Why should I have to edit fstab to enable it?

https://www.netbsd.org/docs/misc/index.html#journal-options

Note that metadata journaling does not help with file corruption when a write operation is interrupted by an unclean shutdown, and can in some cases make it worse.

nia Opinions ... I disagree. Gtk2 is deprecated, whether we like it or, not.

EDIT: GIMP will soon no longer be a Gtk2 app, https://pkgsrc.se/graphics/gimp-devel

jmcunx

nia

I'm still convinced GTK 2 is the best X11 toolkit.

Yes I agree with this. Menus on emacs 29.4 is very slow to appear and sometimes hangs X for a few seconds. This is via gtk3 package.

As a test, I compiled emacs 29.4 via pkgsrc using gtk2, no issues and works much faster. I noticed the same on another BSD OS also. The gtk3 version "fails" were the gtk2 version works great.

bsduck

pin Why not port GIMP straight to GTK 4 at this point? GTK 3 is already considered legacy...