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? I did some limited experiments tonight, but I'm afraid I started too late to get as far as seeing any useful conclusions. But I can try again tomorrow afternoon CET (possibly with new snapshot and packages). All the best, Peter -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/ "Remember to set the evil bit on all malicious network traffic" delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.
