RAM usage quake on upsizing the window

[bodqhrohro]

I'm submitting a…

Bug Report

Current Behavior

When I upsize (f.e., maximize) the LuaKit window, I get a RAM usage quake of luakit process: it grows to more than 1 GB for a while, than falls back to normal.

Expected Behavior

No abrupt changes of RAM usage.

Reproduction Instructions

This seems to be related to the large number of tabs or the large session again. I just tried to spawn 64 empty tabs in a clean session, and couldn't reproduce such a quake. However, the stable RAM usage of luakit process differs depending on the window size:

• quarter of screen: 105 MB;
• half of screen: 168 MB;
• full screen: 283 MB.

I have favicons and vertical tabs enabled, and a compositing WM (Compiz), if matters.

Environment

Linux Distribution & Version: Debian 10. Output of luakit --version: luakit 2.0.0 built with webkit 2.22.6 (installed version: 2.24.1)

[bodqhrohro]

This issue is reproducable with disabled favicons too.

Also, sometimes the memory usage grows because of buffers shared with Xorg. They all have size of 33554432 bytes, and their number may grow up to.tens. Is this a leak or do they have some purpose?

[aidanholm]

That's odd. I can't reproduce this one at all. It's most likely webkit2gtk doing something strange, since luakit doesn't have any gradual garbage collection like the falling back process you describe. It's possible that it could be caused by luakit via unusual use of the webkit APIs, but there's nothing too funny going on in the main process so I think that's probably unlikely.

I would guess that your 32MB buffers shared with xorg are used during rendering, and 32MB is a somewhat common shared memory size limit on some distros. I doubt those are a leak.

Without some profiling of where allocations are happening, e.g. using massif or heaptrack, it's hard to say why this is happening.

[bodqhrohro]

https://0x0.st/zAYn.gz

heaptrack_gui shows very strange results for me. All of peaks are less than 100 MB, though the resident memory usage have grown up to 1.3 GB during this session. Maybe the memory chunks are allocated and freed so often that the kernel cannot keep up and defragment the memory in time? Also, it does not show any symbols, though I installed dbgsym packages for all of luakit, libcairo2, libglib2.0 and libgtk-3; tried to run heaptrack with and without the -d flag, but symbols do not show up in both cases.

[bodqhrohro]

Or maybe it is allocated on the stack? If heaptrack, as it comes from its name, handles only allocations on the heap, it explains pretty good why does it gather the allocations only partially. And the answer by the link explains why is this memory freed with such a strange delay.

Will try massif now, looks like it has an option to watch for the stack too.

[bodqhrohro]

Great, it crashes under massif :->

[  385.685158] E [core/common/util]: unprotected error in call to Lua API (not enough memory)

[aidanholm]

Thanks for the debug dump; unfortunately the only thing that really jumps out at me is the huge rss. Other than that everything looks pretty normal. I don't think runaway allocations confusing the kernel are likely, since the allocations will be served by glibc's allocator. I don't think a runaway stack is likely either; unless you've adjusted your ulimits, the max stack size is usually 8MB.

You could try installing epiphany and seeing if it has the same problem; it uses the same web engine as luakit and I often use it to determine whether problems are caused by webkit.

[bodqhrohro]

Yeah, looks like Epiphany is affected with this issue too. Though I don't have that many tabs there, the RAM usage grow by ~200 MB when maximizing a quarter-screen window. And I don't even know if this is a new issue or I just didn't notice it when I was actively using Epiphany (about a half year ago).

[bodqhrohro]

Some more observations:

• It happens with disabled Gigacage too.
• It happens under Wayland too.

[bodqhrohro]

Is this probably related to re-rendering all the loaded pages? I noticed that pages seem to be rendered completely here, while other modern browser engines split them to small chunks and render them partially (and because of that, some chunks may be rendered with a noticeable lag under heavy load). Can chunky rendering be enabled in WebKitGTK somehow?

[hippi777]

hi there! :)

in that latter case, i think even rendering pages on switching tabs can be enough in the worst case, but i think that it can be checked if the size changed at all before rendering anything new... (note that i still dunno the internals... but one day i will! :D )

bests! :)

[bodqhrohro]

Hey, what is that? Why is there so many of them? o_O