Re: firefox broken on arm64 ; about:config WebGL Disable

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:
>>> 
>>>> From: Jesper Schmitz Mouridsen <jsm_at_FreeBSD.org>
>>>> Date: Sun, 03 Dec 2023 07:34:21 UTC
>>>> 
>>>> On 25.11.2023 00.00, Jesper Schmitz Mouridsen wrote:
>>>>> Hi
>>>>> 
>>>>> 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
>>>>> 
>>>>> /Jsm
>>>> 
>>>> 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.
>>>> 
>>>> Any suggestions on what is going on are appreciated.
>>>> 
>>>> /jsm
>>> 
>>> 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.
>>> 
>>> See if this fixes crashes in versions 115 , 116 or later, Firefox-esr version.  Report back your findings.
>>> 
>>> webgl.disabled    true
>>> 
>> 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
> 
> #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.



===
Mark Millard
marklmi at yahoo.com