From owner-freebsd-questions@freebsd.org Tue Nov 13 21:49:19 2018 Return-Path: Delivered-To: freebsd-questions@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4445A1133784 for ; Tue, 13 Nov 2018 21:49:19 +0000 (UTC) (envelope-from freebsd@edvax.de) Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.126.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "mout.kundenserver.de", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 76BF57A244 for ; Tue, 13 Nov 2018 21:49:18 +0000 (UTC) (envelope-from freebsd@edvax.de) Received: from r56.edvax.de ([92.193.180.181]) by mrelayeu.kundenserver.de (mreue011 [212.227.15.167]) with ESMTPA (Nemesis) id 1Mg6Na-1fqOTF3G1u-00hfsO; Tue, 13 Nov 2018 22:49:15 +0100 Date: Tue, 13 Nov 2018 22:49:15 +0100 From: Polytropon To: B J Cc: freebsd-questions Subject: Re: Kernel Panics With Firefox 63.x Message-Id: <20181113224915.9429e289.freebsd@edvax.de> In-Reply-To: References: <20181113182954.1d7060bd.freebsd@edvax.de> <20181113201830.f0eec001.freebsd@edvax.de> <20181113205020.afc446d9.freebsd@edvax.de> Reply-To: Polytropon Organization: EDVAX X-Mailer: Sylpheed 3.1.1 (GTK+ 2.24.5; i386-portbld-freebsd8.2) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K1:VMQAhlqWtTyJlwI19d0y+jEyblmNMnB3QE6JBhl7X//MlhsoqdO AeqnAec+riFe2nyXhJ1QgXb1p4Zl2qwFyXVRzlxfCb2L0gjsuQ5BvLJDx5dPIF9vGummdwK 6qHdHF5dDRH8hIMjRkj8Q6P5MUDiiIxnevBS0JWchyQ59CGUdwdUp5h1lzd3352llZcx3sV S48TDdUQEwFX+y15xfQJA== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V01:K0:vclPGTFnE9A=:XdYMO95gUnHwinPkTHjqza cMNgXpsmHEErrPUyr33Vci7QYTa9BhAX3LSdqVC7Th1F4CI+p8BZQvlyGJi+Bepr3vHbo+zDe VR2Q2UHi/9TmG4kJSdmKEOrLyQsNgLMRlpBi7ic40lj27BKbbj4oPq6jpP+BfX9WOihaomvMu dHOOPh+Kl8ab/T+5tXpx1u/rLO4RqeyJqD9CKJQV1TbWqh7Ml7NEH9YbodMLmFaV0BT/jqOEL 7ytyQERX+fhpNbbyrwoF6AuAb9wzhHhXFF3aF+4yzzPQpFjPETNiD39AoAjf9XU6KeliPLbWN 6JMOYCmAozngaMPN42Ybcx9NHqKp1g8K4smW0xbs0Q23fYdAKQU2Qb5sIcQ2vybFydGyMYmOl kuYL88J7ghGw+GQk8tiWRua1d7/IUeYn29vYADs26wvn7ALkie7OnnzlMW++cJg5BGZ2pSpKn CQ5nXGQ/wcqeZnvrJdIWI31AMtz1tu16vA9Yy8r9DmMwgUBuf9atCw0AjunT/cNfl5sVF1qRH /4fNXblcXL3lgzSkqD8/Gj//K9Au7wH5BCyg0wZt7BI/2/5Arikj+qEt5jex63NlLT1b3U44J NsnAERFRSLGmFXbzPe1f59ljzT4yloa0FEDt6FYJ/s/Uwcb7NgqfQAM+MvPqR0HxwvaKkSR1C q8EtP+Iw5L2oRCwAvJn0yV5Zm5lgs48KAZ5621Y5s512bP1+nuZ//wVhvP57vKx4S1xHKjfAh a+J1BBaochk3HQD/ATBmuC66Y+AbW+a026M/uTmihwq6tZxMqHdnuGjtnLaFaJdq2KSRWJcnn K04gxcgvzTzgFBwZKqt7lmG8/tLcA== X-Rspamd-Queue-Id: 76BF57A244 X-Spamd-Result: default: False [1.79 / 200.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; HAS_REPLYTO(0.00)[freebsd@edvax.de]; MV_CASE(0.50)[]; HAS_ORG_HEADER(0.00)[]; TO_DN_ALL(0.00)[]; MX_GOOD(-0.01)[cached: mx00.schlund.de]; RCPT_COUNT_TWO(0.00)[2]; FREEMAIL_TO(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:8560, ipnet:212.227.0.0/16, country:DE]; IP_SCORE(0.11)[ipnet: 212.227.0.0/16(-0.11), asn: 8560(0.66), country: DE(-0.01)]; RECEIVED_SPAMHAUS_PBL(0.00)[181.180.193.92.zen.spamhaus.org : 127.0.0.10]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.49)[-0.489,0]; REPLYTO_EQ_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; NEURAL_SPAM_SHORT(0.61)[0.612,0]; NEURAL_HAM_LONG(-0.83)[-0.826,0]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[edvax.de]; AUTH_NA(1.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[131.126.227.212.list.dnswl.org : 127.0.5.0]; MID_CONTAINS_FROM(1.00)[]; R_SPF_NA(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-Rspamd-Server: mx1.freebsd.org X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Nov 2018 21:49:19 -0000 On Tue, 13 Nov 2018 21:04:43 +0000, B J wrote: > > > >> Thanks for the info. It looks like I've got some work ahead of me. > >> I'll look into that once I finish building FF from ports which, as I'm > >> writing this, is still in progress after about 2 hours. > > > > I'd suggest you interrupt the build right now. It _could_ > > happen that a file system inconsistency causes a defective > > binary to be generated without you noticing. Perform the > > forced fsck in SUM first, then "make clean", and finally > > restart the build - just to be sure... > > > > 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. :-) > One thing I didn't mention earlier was that, before I had the kernel > panics earlier today, each time I tried starting FF, I had to reset > everything. Evidently, some of the preference files had been > corrupted but either couldn't be restored or would be damaged each > time I ran it. 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. -- Polytropon Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ...