xpra icon
Bug tracker and wiki

Opened 3 months ago

Last modified 28 hours ago

#1879 new defect

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 3 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 3 months ago.
Chrome HTML5 client debug log with "draw" enabled

Download all attachments as: .zip

Change History (13)

comment:1 Changed 3 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 3 months ago by Antoine Martin (previous) (diff)

Changed 3 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 3 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 3 months ago by J. Max Mena (previous) (diff)

comment:3 Changed 3 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 3 months ago by J. Max Mena

Attachment: 1879chrome.log added

Chrome HTML5 client debug log with "draw" enabled

comment:4 Changed 3 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 3 months ago by Antoine Martin (previous) (diff)

comment:5 Changed 3 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 3 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 3 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 3 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 3 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 3 months ago by Antoine Martin

Milestone: 2.4
Priority: majorcritical
Status: newassigned

comment:11 Changed 28 hours 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?

Note: See TracTickets for help on using tickets.