On Mon, Mar 13, 2017 at 11:19:09PM +0100, Peter N. M. Hansteen wrote:
>
> On 03/13/17 08:01, Landry Breuil wrote:
> >> Alternatively, I would be glad if someone could test the diff below: I
> >> run with it, but I don't use javascript enough to be sure the allocation
> >> isn't too low.
> >>
> >> It makes the allocation to be 128 Mo instead of 1 Go on 64bits platform
> >> (it is the same value than for 32 bits platform in fact).
> >
> > Yet, firefox is unusable on 32-bit hardware. Try *running* it on an atom
> > netbook with 1Gb RAM... so taking the same value as 32 bits platforms
> > isnt an argument :)
> >
> >>From what i read in the various related bugs, the size was increased to
> > fix memory allocation crashes when running WASM (the new 'assembly in
> > javascript' standard) and i think to increase randomization of memory
> > addresses allocated. *shrug*
> >
> > For us, i think coming back to 640M is the "safest" solution.
>
> I've been seeing the same symptoms (firefox-52 crashes with various out
> of memory errors after a few minutes).
>
> What is the most useful way to help debug this? Tweaking staff's
> stacksize-cur upwards, or some other value?
>
the root cause of the segfault is known: firefox allocate a big chunk of
1Go for javascript, and still allocate some memory for others parts of
firefox. so the program will hit RLIMIT_DATA very quickly.
so you had to adjust the datastack-cur limit in your login-class (staff
or default depending the user).
I experimented several things:
- make firefox allocate only 128 Mo for javascript. it works for me,
but I am not a big user of javascript.
- make firefox allocate only 640 Mo for javascript (as landry@
proposed). it should make firefox usable in staff class, but it is
still too much for default class (reminder: the 640 Mo is for
javascript only, the application still do malloc() for others parts
of firefox).
Personally, what bother me is the fact that datastack limit is the same
for all processes, without convenient way (for my knowledge) to run some
programs with alternate class (and bigger datastack).
Else, I would have a "default" login-class with something like 256 Mo of
datastack, and running firefox or libreoffice with alternate login-class
with more datastack (like 2 Go).
I only know su(1) to be able to change the login-class, and the
parameter is reserved to root (and it is normal). So if I want to use it
I have to do something like:
semarie@foo$ doas su -c bigmem semarie -c "firefox"
And I am not very confident for the use of doas(1) and su(1) in the same
command-line...
Alternatively, having a small datastack-cur and a bigger datastack-max
is a possibility, and setting datastack-cur to datastack-max before
running firefox (ulimit -d `ulimit -dH`).
If people have others suggestions, I would be glad to hear them :)
--
Sebastien Marie
