Date: Wed, 31 May 2017 17:00:52 -0700 (PDT) From: "Jeffrey Bouquet" <jbtakk@iherebuywisely.com> To: "Dimitry Andric" <dim@FreeBSD.org> Cc: "FreeBSD Current" <freebsd-current@freebsd.org>, "FreeBSD Ports" <freebsd-ports@freebsd.org> Subject: Re: Firefox (and other Mozilla products) after ino64 Message-ID: <E1dGDXo-00016s-Tf@rmmprod05.runbox> In-Reply-To: <3FD47B4D-1C1E-485E-A305-9C4EF3FB5F74@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 31 May 2017 23:27:16 +0200, Dimitry Andric <dim@FreeBSD.org> 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=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?E1dGDXo-00016s-Tf>