Out-Of-Memory when displaying a very long directory listing

[JoachimHenze]

This is a tough nut most likely. If you can't fix this, I will accept it. Still reporting, in the hope you would be capable.

The following link has a huge directory listing, a very evil testcase: https://iso.reactos.org/bootcd/

Expected result: other browsers like "Opera 12.18 x86" on WinXPSP3 Pro x86 can perfectly show it in its entirety. Opera 12.18 is teachers pet in this benchmark for all browsers that I have ever run this benchmark on, being the fastest one:

Observed result: https://github.com/win32ss/supermium/releases/tag/v124-r2 x86 on WinXPSP3 Pro x86 it loads a while, starts displaying the page (while still loading) and ultimately fails with Out-Of-Memory:

This happens also if I don't have any other tabs open (unlike in my screenshot, where I had several open tabs)

[JoachimHenze]

I have not tested that explicitly, but I could very well imagine that the Chrome upstream sources might be affected by this obvious inefficiency in the implementation as well.

However the Opera-guys implemented that, they found a more efficient, and also more fast/performant solution for such directory-listings than the Google-Chrome-guys.

[win32ss]

I can confirm this as well. Renderer process commits about 2.5 GB on Supermium 126 x64 when it finishes loading that page, well above any practical 32 bit limit. Google Chrome 126 is even worse at about 2.75 GB. But then I tried Google Chrome 49, and about 300 MB is committed and the page loads successfully.

So this is reversible even in a Chromium context, but it may take some time.

[JoachimHenze]

Thank you for this in-depth-check. Reverting to Chrome 49 way to do things sounds like a good idea. If you know the official Chromium-bug-tracker, it might still make sense to create an upstream-copy of that Defect also on their side. Regardless of the way that Supermium will take. It's something whole mankind might want to benefit from, not just the small Supermium-Elite. ;-)

[Vangelis66]

... I myself stumbled on this very bug :angry: yesterday, while trying to load:

https://chromium.googlesource.com/chromium/src/+log/121.0.6167.185..122.0.6261.58?pretty=fuller&n=10000

in my 32-bit copy of Sm-v124-r2, portable installation on Windows Vista SP2 x86, with a total of 3 (1+2) GB of installed RAM; FWIW, I was trying to pinpoint the exact commits Google Devs authored to remove the underlying code that allowed the cmdline switch --disable-features=UserAgentClientHint to work as expected until Chrome M121 (see #838) ...

[narinishi]

Interestingly, I am able to load that ReactOS link with 32-bit Supermium 124 on 64-bit Windows 8.1

[lbwq63]

I can confirm this as well. Renderer process commits about 2.5 GB on Supermium 126 x64 when it finishes loading that page, well above any practical 32 bit limit. Google Chrome 126 is even worse at about 2.75 GB. But then I tried Google Chrome 49, and about 300 MB is committed and the page loads successfully.

So this is reversible even in a Chromium context, but it may take some time.

Is modern Chromium that inefficient? Anyone can try on Firefox to see how much memory is consumed?

[Ravenant1234]

Interestingly, I am able to load that ReactOS link with 32-bit Supermium 124 on 64-bit Windows 8.1

Can u test with 64-bit Supermium to compare results?

[XakerTwo]

OS: Win 7 SP1 x64

Supermium 124 R2 x64

what we are telling about? look at `about:blank` - it's not 30 or 60 it's damned 120+ 

FF 115 LTS x64

Well, it's much better - peak usage is about 1092MB! regular usage on screenshot but it's untouched and commonly not used FF 115, FF 117 Nightly not fully transfered yet and can't be tested 

... ... when will superfox be released?..

[Ravenant1234]

Well, in tor 13.5.2 this issue also happens

[Vangelis66]

... Just for laughs, I decided to try the offending URL in first post in my KafanMiniBrowser, which is a Chromium 87 32-bit fork, able to run perfectly in my Vista SP2 32-bit OS, with a total of 3 GB of (DDR2) RAM installed :wink: ; it actually took ca. 8min (!) for the page to complete loading, hammering both cores of my old Core2Duo, but it did not crash with an OutOfMemory :+1: ; once fully loaded, the tab process consumes a little more than 1 GB of memory:

So, apparently, one doesn't need to go that far back to Chrome 49 for a successful loading of the URL on a 32-bit browser, on a 32-bit OS :stuck_out_tongue_winking_eye: ; with Win10 going out of Extended Support in 2025 for "the masses" and Win11 available only as 64-bit, RAM consumption by Google Chrome will only worsen, as Google :rage: Devs will think it a given everyone using it is already on a x64 OS with 32+GB of RAM :disappointed: :angry: ...