xpra icon
Bug tracker and wiki

Opened 5 months ago

Closed 11 days ago

#1879 closed defect (fixed)

Memory Leak in HTML5 Client

Reported by: J. Max Mena Owned by: J. Max Mena
Priority: critical Milestone: 2.4
Component: html5 Version: trunk
Keywords: Cc:

Description (last modified by Antoine Martin)

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

Attachments (2)

1879info.txt (113.6 KB) - added by J. Max Mena 5 months ago.
Xpra info after the memory had climbed at least a few hundred MBs
1879chrome.log (478.3 KB) - added by J. Max Mena 5 months ago.
Chrome HTML5 client debug log with "draw" enabled

Download all attachments as: .zip

Change History (17)

comment:1 Changed 5 months ago by 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.

Last edited 5 months ago by Antoine Martin (previous) (diff)

Changed 5 months ago by J. Max Mena

Attachment: 1879info.txt added

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

comment:2 Changed 5 months ago by J. Max Mena

Description: modified (diff)

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

Last edited 5 months ago by J. Max Mena (previous) (diff)

comment:3 Changed 5 months ago by Antoine Martin

Description: modified (diff)
Owner: changed from Antoine Martin to J. Max Mena

Is this reproducible without "video" enabled?

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

Changed 5 months ago by J. Max Mena

Attachment: 1879chrome.log added

Chrome HTML5 client debug log with "draw" enabled

comment:4 Changed 5 months ago by J. Max Mena

Owner: changed from J. Max Mena to Antoine Martin

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.

Last edited 5 months ago by Antoine Martin (previous) (diff)

comment:5 Changed 5 months ago by Antoine Martin

Owner: changed from Antoine Martin to J. Max Mena

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?

comment:6 Changed 5 months ago by 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.

comment:7 Changed 5 months ago by J. Max Mena

Owner: changed from J. Max Mena to Antoine Martin

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.

comment:8 Changed 5 months ago by Antoine Martin

Owner: changed from Antoine Martin to J. Max Mena

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.

comment:9 Changed 5 months ago by J. Max Mena

Owner: changed from J. Max Mena to Antoine Martin

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.

comment:10 Changed 5 months ago by Antoine Martin

Milestone: 2.4
Priority: majorcritical
Status: newassigned

comment:11 Changed 8 weeks ago by Antoine Martin

Owner: changed from Antoine Martin to J. Max Mena
Status: assignednew

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?

comment:12 Changed 4 weeks ago by J. Max Mena

Owner: changed from J. Max Mena to Antoine Martin

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.

comment:13 Changed 4 weeks ago by Antoine Martin

Owner: changed from Antoine Martin to 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.
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.

comment:14 Changed 2 weeks ago by 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)

comment:15 Changed 11 days ago by J. Max Mena

Resolution: fixed
Status: newclosed

(actually close the ticket)

Note: See TracTickets for help on using tickets.