Xpra: Ticket #1879: Memory Leak in HTML5 Client

Followup from #1839:

There is a memory leak in the HTML5 client. It was found using Chrome 67.0.3396.79 on Fedora 28.

The repro steps are fairly straightforward:

I'll repro this again and then attach an xpra info

TODO:



Thu, 14 Jun 2018 19:00:45 GMT - J. Max Mena:

While getting the Xpra info - I noticed you don't need the console open to get the memory to climb steadily - as mentioned in ticket:1839#comment:9.


Thu, 14 Jun 2018 19:04:23 GMT - J. Max Mena: attachment set

Xpra info after the memory had climbed at least a few hundred MBs


Thu, 14 Jun 2018 20:15:02 GMT - J. Max Mena: description changed

Double checked with Chrome 67.0.3396.87 and Firefox 60.0.2 on Win8.1 and saw the memory climb steadily as well.


Thu, 14 Jun 2018 23:41:54 GMT - Antoine Martin: owner, description changed

Is this reproducible without "video" enabled?

Please include the javascript console output with "draw" debugging enabled.


Mon, 18 Jun 2018 16:59:00 GMT - J. Max Mena: attachment set

Chrome HTML5 client debug log with "draw" enabled


Mon, 18 Jun 2018 17:00:17 GMT - J. Max Mena: owner changed

Yes it is reproducible without Video enabled - I just posted a log with video disabled and I still saw the memory climb.

The logs in question are with a Chrome window pointed at YouTube with a video playing at ~720p.


Mon, 18 Jun 2018 17:15:57 GMT - Antoine Martin: owner changed

Yes it is reproducible without Video enabled - I just posted a log with video disabled and I still saw the memory climb.

By how much? Does the memory go back down when you close the window that contained the video? (the chrome window in your case - and by how much?) Can you identify which encodings trigger the leak? (png, webp, jpeg?) Or all of them?


Mon, 18 Jun 2018 17:18:19 GMT - J. Max Mena:

In the time it took to capture that log, the memory had increased by at least 500-600MB. After closing the window - it dropped almost instantly.


Mon, 18 Jun 2018 17:24:11 GMT - J. Max Mena: owner changed

I can reliably trigger it with both JPEG and PNG as encoding options - but I found it climbed notably faster with PNG. My session wouldn't connect with rawRGB - I think I'm missing a package on my server.


Mon, 18 Jun 2018 17:45:23 GMT - Antoine Martin: owner changed

After closing the window - it dropped almost instantly.

Are we talking about the window that is the whole xpra client or the window within that is being forwarded? I'm interested in the window that is forwarded.


Mon, 18 Jun 2018 17:49:17 GMT - J. Max Mena: owner changed

Ah, I see.

I was referring to the Local Window - the one that had the HTML5 client. Closing that causes the memory to drop - even if it's just a tab and not the whole Chrome window.

Closing the forwarded window has no impact at all - the memory holds steady.


Wed, 27 Jun 2018 13:07:26 GMT - Antoine Martin: priority, status changed; milestone set


Mon, 24 Sep 2018 16:41:35 GMT - Antoine Martin: owner, status changed

Where did you see this memory going up? I'm looking at the memory profiler in google chrome and it is steady at:

Did you have sound enabled, did you try turning that off? As per comment:5 and comment:8, does closing the xpra forwarded window (not the browser window) bring the memory back down?


Tue, 23 Oct 2018 17:41:55 GMT - J. Max Mena: owner changed

Did a quick follow-up for this one (while checking #1816), and it's still an issue as of r20799.

Crucially, I think the memory leak is centered around the dev-tools; the console in particular. If you load up a video and watch it, the memory does not climb regularly (you can see the Chrome task manager by hitting shift + escape) unless you have the console open. If you open up the console and watch the logs, the memory climbs steadily - if you have mpeg1 or h264 enabled, it seems to climb much quicker. Notably, both the "xpra websockets client" and the dev-tools processes are the ones that have a very steady memory climb. From what I can tell, the dev-tools climb much quicker.

Closing the dev-tools immediately releases a large amount of the memory. I'm not entirely sure if it releases all of the memory, but it is a notable amount for sure.

It's still triggerable - you just need to watch it for a few minutes. It climbs very quickly on my workstation (Fedora 28) if I'm watching a video.

To answer your questions in order:

Where did you see this memory going up?

Chrome > Task Manager shift + escape

Did you have sound enabled, did you try turning that off?

Disabled.

As per comment:5 and comment:8, does closing the xpra forwarded window (not the browser window) bring the memory back down?

No. As mentioned in comment:4 it has no effect - only closing the client's windows seem to release the memory on the client system.


Tue, 23 Oct 2018 18:18:22 GMT - Antoine Martin: owner changed

If it is the developer tools that are using the memory then we don't really care: those that choose to use these tools should know the risks. They will have to consume a lot of memory to do their job, that's just how they work. And they may even cause memory leaks as they keep ref-counting things.

What we care about is normal usage, regular users doing regular things. If the chrome (or firefox or whatever) process doesn't leak any memory then let's just close this ticket.


Thu, 01 Nov 2018 16:59:17 GMT - J. Max Mena:

If it is the developer tools that are using the memory then we don't really care: those that choose to use these tools should know the risks.

Sounds good to me. I haven't seen any memory leaks without the dev-tools open, so I'm gonna go ahead and close this. (Finally)


Tue, 06 Nov 2018 17:47:12 GMT - J. Max Mena: status changed; resolution set

(actually close the ticket)


Sat, 23 Jan 2021 05:36:13 GMT - migration script:

this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/1879