Date: Tue, 5 Dec 2023 13:58:03 -0800 From: Mark Millard <marklmi@yahoo.com> To: Jesper Schmitz Mouridsen <jsm@FreeBSD.org> Cc: "Fred G. Finster" <fred@thegalacticzoo.com>, freebsd-arm <freebsd-arm@freebsd.org>, void <void@f-m.fm> Subject: Re: firefox broken on arm64 ; about:config WebGL Disable Message-ID: <D3216F3F-5A55-49CE-BE22-6817C9E6DFF0@yahoo.com> In-Reply-To: <e19ca7e7-2e28-4dcf-be10-6e79c97cd5fb@FreeBSD.org> References: <330d85af-0db3-d517-d2ee-6fe58228335e@thegalacticzoo.com> <7147d3e6-7354-46d6-a08a-7064eb14e534@FreeBSD.org> <e19ca7e7-2e28-4dcf-be10-6e79c97cd5fb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Dec 5, 2023, at 13:00, Jesper Schmitz Mouridsen <jsm@FreeBSD.org> = wrote: > On 05.12.2023 00.18, Jesper Schmitz Mouridsen wrote: >> On 04.12.2023 23.50, Fred G. Finster wrote: >>>=20 >>>> From: Jesper Schmitz Mouridsen <jsm_at_FreeBSD.org> >>>> Date: Sun, 03 Dec 2023 07:34:21 UTC >>>>=20 >>>> On 25.11.2023 00.00, Jesper Schmitz Mouridsen wrote: >>>>> Hi >>>>>=20 >>>>> Tabs crashes with signal 4 on arm64 not firefox 115 esr but = librewolf 117 dies as well as firefox 119 and 120. Hve not tested 116. >>>>> example = https://gist.github.com/jsm222/e6199a03142f5716921c82c3d2f3ddc5 >>>>>=20 >>>>> /Jsm >>>>=20 >>>> Just build firefox-esr-115.5.0_1,1 and firefox-116.0.3_1,2 the = first runs with aslr disabled, the latter signals 4. >>>>=20 >>>> Any suggestions on what is going on are appreciated. >>>>=20 >>>> /jsm >>>=20 >>> JSM, Void, other fellow FreeBSD-ARM users >>> See if from inside FireFox, you open URL about:config >>> find webgl.disabled and set it to value TRUE. >>>=20 >>> See if this fixes crashes in versions 115 , 116 or later, = Firefox-esr version. Report back your findings. >>>=20 >>> webgl.disabled true >>>=20 >> Did not work for me on rpi4 with 4GB ram with firefox 119 from stock = packages.. Perhaps it is just a masked OOM problem.. > So perhpaps it is just lack of memory for > 115-esr.. (I have at most = 4GB arm sbcs) > With kern.elf64.allow_wx: 0 > I do get a OOM condition >=20 > #0 0x0000189a88aaf298 in NS_ABORT_OOM(unsigned long) () from = /usr/local/lib/firefox/libxul.so > [Current thread is 1 (LWP 102755)] > (gdb) bt > #0 0x0000189a88aaf298 in NS_ABORT_OOM(unsigned long) () at = /usr/local/lib/firefox/libxul.so > #1 0x0000189a89190614 in XPCJSContext::Initialize() () at = /usr/local/lib/firefox/libxul.so > #2 0x0000189a89190a58 in XPCJSContext::NewXPCJSContext() () at = /usr/local/lib/firefox/libxul.so > #3 0x0000189a891ba3d4 in xpc::InitializeJSContext() () at = /usr/local/lib/firefox/libxul.so > #4 0x0000189a88b8c2b4 in NS_InitXPCOM () at = /usr/local/lib/firefox/libxul.so > #5 0x0000189a8b224584 in mozilla::dom::ContentProcess::Init(int, = char**) () at /usr/local/lib/firefox/libxul.so > #6 0x0000189a8c53912c in XRE_InitChildProcess(int, char**, = XREChildData const*) () at /usr/local/lib/firefox/libxul.so > #7 0x00001899d60a2574 in main () Could you have a swap partition configured so the space limit is more like RAM+SWAP? (SWAP < about 3.8*RAM if one avoids sizes that get warnings about potential mistuning. Ways of adjusting to allow more swap without the messages have other tradeoffs that I do not understand well enough to be willing to go that direction.) I do not recommend swap files for FreeBSD. Too much chance of deadlocks: On 2017-Feb-13, at 7:20 PM, Konstantin Belousov <kostikbel at gmail.com> wrote on the freebsd-arm list: . . . swapfile write requires the write request to come through the filesystem write path, which might require the filesystem to allocate more memory and read some data. E.g. it is known that any ZFS write request allocates memory, and that write request on large UFS file might require allocating and reading an indirect block buffer to find the block number of the written block, if the indirect block was not yet read. As result, swapfile swapping is more prone to the trivial and = unavoidable deadlocks where the pagedaemon thread, which produces free memory, needs more free memory to make a progress. Swap write on the raw partition = over simple partitioning scheme directly over HBA are usually safe, while = e.g. zfs over geli over umass is the worst construction. =3D=3D=3D Mark Millard marklmi at yahoo.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?D3216F3F-5A55-49CE-BE22-6817C9E6DFF0>