From owner-freebsd-current@freebsd.org Thu Jun 1 00:01:02 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 358FDBED5B5; Thu, 1 Jun 2017 00:01:02 +0000 (UTC) (envelope-from jbtakk@iherebuywisely.com) Received: from aibo.runbox.com (aibo.runbox.com [91.220.196.211]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id EBDE5719CD; Thu, 1 Jun 2017 00:01:01 +0000 (UTC) (envelope-from jbtakk@iherebuywisely.com) Received: from [10.9.9.127] (helo=rmmprod05.runbox) by mailtransmit03.runbox with esmtp (Exim 4.86_2) (envelope-from ) id 1dGDXo-0001KA-Uj; Thu, 01 Jun 2017 02:00:53 +0200 Received: from mail by rmmprod05.runbox with local (Exim 4.86_2) (envelope-from ) id 1dGDXo-00016s-Tf; Thu, 01 Jun 2017 02:00:52 +0200 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Received: from [Authenticated user (846156)] by runbox.com with http (RMM6); Thu, 01 Jun 2017 00:00:52 GMT From: "Jeffrey Bouquet" To: "Dimitry Andric" CC: "FreeBSD Current" , "FreeBSD Ports" Subject: Re: Firefox (and other Mozilla products) after ino64 Date: Wed, 31 May 2017 17:00:52 -0700 (PDT) X-Mailer: RMM6 In-Reply-To: <3FD47B4D-1C1E-485E-A305-9C4EF3FB5F74@FreeBSD.org> Message-Id: X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jun 2017 00:01:02 -0000 On Wed, 31 May 2017 23:27:16 +0200, Dimitry Andric wrote: > Hi, >=20 > Due to the recent ino64 update in 12.0-CURRENT, there have been some > reports by Firefox port users about crashes. While I personally have > not experienced these crashes, as I immediately rebuilt all my ports > from scratch after the ino64 update, I think can explain why the > following combination is very likely to have problems: >=20 > * kernel+world after ino64 > * www/firefox package from before ino64 >=20 > It is because Firefox's JavaScript engine is doing tricks to get at libc > structures and functions (via an FFI mechanism), and several structure > layouts and offsets are hardcoded into its engine at build time. >=20 > For instance, here is the place where the engine determines the offset > of struct dirent's d_name field: >=20 > https://hg.mozilla.org/mozilla-central/file/tip/dom/system/OSFileConsta= nts.cpp#l648 >=20 > Further down in the file, several offsets of fields in struct stats are > similarly determined: >=20 > https://hg.mozilla.org/mozilla-central/file/tip/dom/system/OSFileConsta= nts.cpp#l677 >=20 > Now, since ino64 changed quite a number of structure layouts, including > struct dirent, struct stat, and others, such offsets determined in the > past will no longer be valid! >=20 > It is pretty likely that Firefox will attempt to access these fields, > finding bogus values, or simply reading invalid memory, and crashing > because of this. Or at the least, the behavior will be unstable. >=20 > This also applies to other Mozilla products, such as Thunderbird, > SeaMonkey, and so on. These should all be rebuilt from scratch under > ino64. >=20 > -Dimitry What of machines where for some reason ports do not always build? [ for ins= tance,=20 ones with past workarounds for a failed installworld... ] that still are in critical use daily? And,or whe= re the system has been installed for so long without reinstall that some ports=20 segfault unless 'pkg lock' ... and not usually upgraded... and/or thus usi= ng binaries from backup...=20 Are upstream repositories to have those [ browser, email] ports? For in= stance, here iridium I cannot get to build...=20=