RESOLVED DUPLICATE of bug 245222 241012
WPE aborts in RaspberryPi 4 with: "The renderer process ran out of memory"
https://bugs.webkit.org/show_bug.cgi?id=241012
Summary WPE aborts in RaspberryPi 4 with: "The renderer process ran out of memory"
Manuel A. Fernandez Montecelo
Reported 2022-05-27 07:21:28 PDT
About 30 seconds after starting the browser, even with simple internal pages like "webkit://gpu", the renderer aborts. The error reported within the browser window and the terminal is: 11(cog:717): Cog-Core-WARNING **: 13:54:54.429: <webkit://gpu/> Out of memory!: The renderer process ran out of memory. You may try reloading the page to restart it. This happens on 32-bit builds for RaspberryPi4, Zan Dobersek traced it to: https://github.com/WebKit/WebKit/blob/main/Source/WTF/wtf/MemoryPressureHandler.cpp#L98 ... using sizes larger than size_t in 32-bits, and overflowing and getting to size=0 when adding 7+1GB when tabCount=1.
Attachments
Guillaume Emont
Comment 1 2022-06-10 01:55:24 PDT
I can reproduce it on a raspberry pi 3 (running in 32-bits). This log line might be more telling: Unable to shrink memory footprint of process (80 MB) below the kill thresold (0 MB). Killed I can work around it with a recent version of cog (tried with 0.13.3) by passing it the option --web-kill-threshold=600 or whatever value makes sense with the amount of RAM you have.
Nikolas Zimmermann
Comment 2 2022-09-14 00:50:05 PDT
Confirmed on another embedded device, tracked this down yesterday and finished this morning with the same conclusion. In MemoryPressureHandler thresholdForMemoryKillOfInactiveProcess() returns 0 (where it is supposed to compute 'constant + N * something', so should always be > 0, unless things e.g. overflow, as Zan pointed out). Anyhow, Miguel recently added fine-grained configuration possibilities for the MemoryPressureHandler behavior. So the choice for the embedder is to either specify the optional MemoryPressure related settings (shrinkOrDie() will then use the killFractionThreshold from the 'Configuration' rather than some hard-coded formulas, given the embedder a real choice to influence the memory pressure reactions). This is opt-in at present and thus the default behavior in main is broken.
Miguel Gomez
Comment 3 2022-09-15 04:06:52 PDT
Miguel Gomez
Comment 4 2022-09-15 04:16:37 PDT
When I implemented the configuration support for the MemoryPressureHandler, active processes were never killed unless the application set a killThreshold through the configuration. After that Apple added a default threshold to kill processes, which is the value that's overflowing on 32 bits systems. But we shouldn't be using Apple's default values as we don't kill any process unless the application has explicitly set a killThreshold value through the MemoryPressureHandler configuration. The PR I've sent stops using Apple's thresholds for killing processes and uses only the values set to the MemoryPressureHandler's configuration to decide whether a process must be killed or not.
Miguel Gomez
Comment 5 2022-09-16 00:32:51 PDT
The overflow problem has been already fixed by https://commits.webkit.org/254533@main so this can be closed as a duplicate of that one. What I was trying to do here was, instead of just fixing the overflow, was matching the behavior with what's explained in the MemoryPressureHandler documentation, which is that no process is killed if there's no killThreshold defined. Then, as Michael mentioned in the PR, it's true that in many cases we would like to keep a reasonable threshold to kill the process even if the app is not setting a value through the MemoryPressureHandler configuration. So I'm just going to close this as a duplicate of https://bugs.webkit.org/show_bug.cgi?id=245222 and close the PR. Eventually I'll change the MemoryPressureHandler documentation to state that if the app doesn't set a killThreshold, we will use a default value. *** This bug has been marked as a duplicate of bug 245222 ***
Olivier Blin
Comment 6 2022-09-16 00:43:28 PDT
Thanks for the update Miguel, sorry I do not notice that you were already working on this.
Miguel Gomez
Comment 7 2022-09-16 04:44:25 PDT
(In reply to Olivier Blin from comment #6) > Thanks for the update Miguel, sorry I do not notice that you were already > working on this. No problem Olivier! thanks for the fix! ;)
Note You need to log in before you can comment on or make changes to this bug.