Memory Leak in HTML5 Client

[totaam]

Issue migrated from trac ticket # 1879

component: html5 | priority: critical | resolution: fixed

2018-06-14 19:57:44: maxmylyn created the issue

---

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:

• Start up a session

• Open up an application that plays videos

  • for reference I found it by watching YouTube videos in Chrome (connected via Chrome..), but I've reliably reproduced it by watching videos in VLC. So far I have seen no correlation between the video size and if the leak shows up.

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

TODO:

• Check other browsers and OSs

• Console output

[totaam]

2018-06-14 20:00:45: maxmylyn commented

---

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

[totaam]

2018-06-14 20:04:24: maxmylyn uploaded file 1879info.txt (113.6 KiB)

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

[totaam]

2018-06-14 21:15:02: maxmylyn edited the issue description

[totaam]

2018-06-14 21:15:02: maxmylyn commented

---

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

[totaam]

2018-06-15 00:41:55: antoine changed owner from antoine to maxmylyn

[totaam]

2018-06-15 00:41:55: antoine edited the issue description

[totaam]

2018-06-15 00:41:55: antoine commented

---

Is this reproducible without "video" enabled?

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

[totaam]

2018-06-18 17:59:01: maxmylyn uploaded file 1879chrome.log (478.3 KiB)

Chrome HTML5 client debug log with "draw" enabled

[totaam]

2018-06-18 18:00:17: maxmylyn changed owner from maxmylyn to antoine

[totaam]

2018-06-18 18:00:17: maxmylyn commented

---

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.

[totaam]

2018-06-18 18:15:57: antoine changed owner from antoine to maxmylyn

[totaam]

2018-06-18 18:15:57: antoine commented

---

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?

[totaam]

2018-06-18 18:18:20: maxmylyn commented

---

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.

[totaam]

2018-06-18 18:24:12: maxmylyn changed owner from maxmylyn to antoine

[totaam]

2018-06-18 18:24:12: maxmylyn commented

---

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.

[totaam]

2018-06-18 18:45:23: antoine changed owner from antoine to maxmylyn

[totaam]

2018-06-18 18:45:23: antoine commented

---

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.

[totaam]

2018-06-18 18:49:18: maxmylyn changed owner from maxmylyn to antoine

[totaam]

2018-06-18 18:49:18: maxmylyn commented

---

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.

[totaam]

2018-06-27 14:07:27: antoine changed priority from major to critical

[totaam]

2018-06-27 14:07:27: antoine changed status from new to assigned

[totaam]

2018-09-24 17:41:35: antoine changed status from assigned to new

[totaam]

2018-09-24 17:41:35: antoine changed owner from antoine to maxmylyn

[totaam]

2018-09-24 17:41:35: antoine commented

---

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

• ~10 / 45 MB for the main page
• ~7 / 12 for Protocol.js
• 1.1 / 3.7 MB for wsworker_check.js

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?

[totaam]

2018-10-23 18:41:55: maxmylyn changed owner from maxmylyn to antoine

[totaam]

2018-10-23 18:41:55: maxmylyn commented

---

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

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.

[totaam]

2018-10-23 19:18:22: antoine changed owner from antoine to maxmylyn

[totaam]

2018-10-23 19:18:22: antoine commented

---

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.

[totaam]

2018-11-01 16:59:18: maxmylyn commented

---

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)

[totaam]

2018-11-06 17:47:13: maxmylyn changed status from new to closed

[totaam]

2018-11-06 17:47:13: maxmylyn set resolution to fixed

[totaam]

2018-11-06 17:47:13: maxmylyn commented

---

(actually close the ticket)