On Mon, Mar 13, 2017 at 06:34:12AM +0100, Sebastien Marie wrote: > On Sun, Mar 12, 2017 at 10:00:55PM +0100, frantisek holop wrote: > > it seems that i can 100% crash firefox by trying to use > > the web.whatsapp.com client for varying lengths of > > time. this seems to be a regression, is anyone else > > seeing this? > > > > with firefox-52.0, the way memory allocation is done for javascript has > changed: > > - Bug 1334933 - Allocate executable pages from a pre-reserved range. > https://hg.mozilla.org/releases/mozilla-release/rev/6b35bbf96b67 > > and in the same release, the size of initial malloc has been raised from > 640Mo to 1Go: > > - Bug 1337561 - Baldr: call largeAllocationCallback and retry if executable > allocation fails. r=jandem, a=jcristau > https://hg.mozilla.org/releases/mozilla-release/rev/65bb26d07408 > > > It makes firefox to malloc a chunk of 1Go at startup. > > As you crash after the start, I assume you are running in "staff" class > or have modified login.conf datastack-cur value in "default" class. > > The current way to deal with that is to raise your datastack-cur to make > firefox to fit in... > > > 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.
