Kernel Panics With Firefox 63.x

[B J]

On 11/13/18, Polytropon <freebsd at edvax.de> wrote:

<snip>

>> I halted the building process and did as you suggested earlier.  There
>> were indeed a number of inconsistencies and corrupted files when I ran
>> fsck in single-user mode.
>
> Excellent!
>
> Always make sure the file system consistency is present
> _before_ the system boots; relying on background fsck
> just asks trouble. ;-)
>
> Technical sidenote: The background fsck can only handle
> a subset of errors. Common errors, sure, but sometimes
> there is something it cannot correct or repair, and you
> boot into an inconsistent system state, but without any
> warning. A foreground fsck makes sure that _if_ such a
> problem is recognized, you will be interactively prompted,
> so you can decide what to do. In very few cases you do
> _not_ want fsck to do anything, as it might make data
> recovery more problematic; for example, you first decide
> to "mount -o ro /something", retrieve data, then run
> fsck and maybe end up with zero length files (whose
> content you have already recovered), and then you "re-fill"
> those files; or you need to use fsdb to help fsck with
> a problem it cannot work around.
>
> However, for typical use, a foreground fsck will be the
> right thing to do. You gain safety by paying with downtime.
> You usually don't pay with data loss. :-)

I've used fsck when working with external hard drives, but it never
dawned on me to use it for the main one.

<snip>

> Firefox today uses a quite complex structure of files to
> store settings. Combine this with a file system inconsistency,
> and you can easily end up with files that get rewritten or
> reset, but are still damaged at the next program start.
> In case the same inodes were used, the file would always
> be somehow damaged, and even if a process of unlink() and
> open() / fopen() to create it would allocate a different
> inode, it's still possible that the problem was within the
> parent inode - and only a proper fsck would have been able
> to fix this problem.

<snip>

I remember that Firefox used to be shown as a single process when
running top.  In the last year or so, it was changed and now it uses
several of them.  If I want to kill FF, I have to do it to just about
every one of them.  How many there are seems to be related to factors
such as the number of tabs or windows I might have open.

I've been running the newly-installed FF for the past few hours and
there hasn't been any problems yet.

BMJ