241012 2022-05-27 07:21:28 -0700 WPE aborts in RaspberryPi 4 with: "The renderer process ran out of memory" 2022-09-16 04:44:25 -0700 1 1 1 Unclassified WebKit New Bugs WebKit Nightly Build Other Linux RESOLVED DUPLICATE 245222 https://bugs.webkit.org/show_bug.cgi?id=245222 P2 Normal --- 1 mafm magomez guijemont magomez mcatanzaro olivier.blin pnormand psaavedra zdobersek zimmermann oldest_to_newest 1872320 0 mafm 2022-05-27 07:21:28 -0700 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. 1875200 1 guijemont 2022-06-10 01:55:24 -0700 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. 1898412 2 zimmermann 2022-09-14 00:50:05 -0700 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. 1898665 3 magomez 2022-09-15 04:06:52 -0700 Pull request: https://github.com/WebKit/WebKit/pull/4375 1898671 4 magomez 2022-09-15 04:16:37 -0700 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. 1898919 5 magomez 2022-09-16 00:32:51 -0700 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 *** 1898922 6 olivier.blin 2022-09-16 00:43:28 -0700 Thanks for the update Miguel, sorry I do not notice that you were already working on this. 1898948 7 magomez 2022-09-16 04:44:25 -0700 (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! ;)