VLC is using up to 2 GB of RAM just to play a regular 720px HD video

[Wirawan Purwanto]

On my computer running Ubuntu 20.04 and XFCE desktop, The VLC GUI player is using an increasing amount of memory as time progressed. The video is a typical H.264 movie (MP4 file format). I have let the application sit for a few days, and here is the usage of RAM as the days went by:

Date Time(EDT) VSIZE RSS
2020-07-19 20:19:16 2848984 455148
2020-07-20 13:09:06 3307736 926156
2020-07-22 13:18:05 4487464 2059848

The process itself was started on:
Sat Jul 18 21:41:24 2020

I was playing the video only for about ~5 minutes when the program started, then let the program sit idle for a few days. Today I found that it consumed 2GB RSS as shown above!

I am reporting this issue to see if something in my system is messing up VLC memory usage. In an older laptop, trying to play the same file (with VLC version 2.0.3) has its memory consumption starting at just under 190M.

Wirawan

ProblemType: Bug
DistroRelease: Ubuntu 20.04
Package: vlc 3.0.9.2-1
ProcVersionSignature: Ubuntu 5.4.0-40.44-generic 5.4.44
Uname: Linux 5.4.0-40-generic x86_64
NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair
ApportVersion: 2.20.11-0ubuntu27.4
Architecture: amd64
CasperMD5CheckResult: skip
CurrentDesktop: XFCE
Date: Wed Jul 22 13:19:21 2020
SourcePackage: vlc
UpgradeStatus: No upgrade log present (probably fresh install)

[Sebastian Ramacher (s-ramacher)]

This sounds like driver issue. Please provide logs using vlc -vvv from the machine experiencing high memory consumption.

[Wirawan Purwanto (wirawan0)]

Hi folks, an update on my VLC measurement. I finally did that "vlc -vvv", please see attachments for the stderr. I don't see anything interesting there. But I did make snapshots of the vsize, rss, and the "smaps" file under the /procfs/$PID/smaps --they are also attached. I played the same video for less than 12 minutes then paused it. Then let the window sit there like what I did before. The observation covered for about 20 hours total.

The file "vlc-vvv-usage-wirawan2-Sisters_M16.txt" contains the output of "ps faux" commands taken over regular interval (timestamp shown as cols 1-2) for this one process.

I plotted the vsize and rss from that ps output file (using pandas, in case you're curious), I did see linear growth in the memory usage in several stretches of time. And these stretches did not grow with the same rate. I omitted the first line of the measurement because it is not relevant (vlc was being started).

The smap files are timestamped with the UNIX time and the date/time--the meaning should be clear from the filename. I supplied you three snapshots:

* `smaps-1596468720-20200803T113241.txt`: about 5 minutes into the video playing (still running)
* `smaps-1596510832-20200803T231352.txt`: about 12 hours later (video paused)
* `smaps-1596540657-20200804T073057.txt`: about 20 hours later (video paused)

I did see some new memory regions allocated and it was not clear what they are. But that's all the clue I could gather from my testings. Hope all these help pinpointing the cause of the memory leak.

Here is an example analysis:

~~~
$ diff -y --width=200 <(grep -e '^[0-9a-f]+-[0-9a-f]+' -e 'Dirty' -e Rss smaps-1596468720-20200803T113241.txt) <(grep -e '^[0-9a-f]+-[0-9a-f]+' -e 'Dirty' -e Rss smaps-1596510832-20200803T231352.txt) |less
...

7fc19ec74000-7fc19ed74000 rw-s 00000000 00:1a 264 /i915 (deleted) | 7fc188000000-7fc18b61a000 rw-p 00000000 00:00 0
Rss: 404 kB | Rss: 55400 kB
Shared_Dirty: 0 kB Shared_Dirty: 0 kB
Private_Dirty: 404 kB | Private_Dirty: 55400 kB
7fc19ed74000-7fc19ed88000 rw-s 00000000 00:1a 802 /i915 (deleted) | 7fc18b61a000-7fc18c000000 ---p 00000000 00:00 0
Rss: 4 kB | Rss: 0 kB
Shared_Dirty: 0 kB Shared_Dirty: 0 kB
Private_Dirty: 4 kB | Private_Dirty: 0 kB
                                                                                                   > 7fc190000000-7fc198000000 rw-p 00000000 00:00 0
                                                                                                   > Rss: 131072 kB
                                   ...

[Wirawan Purwanto (wirawan0)]

Hi folks, an update on my VLC measurement. I finally did that "vlc -vvv", please see attachments for the stderr. I don't see anything interesting there. But I did make snapshots of the vsize, rss, and the "smaps" file under the /procfs/$PID/smaps --they are also attached. I played the same video for less than 12 minutes then paused it. Then let the window sit there like what I did before. The observation covered for about 20 hours total.

The file "vlc-vvv-usage-wirawan2-Sisters_M16.txt" contains the output of "ps faux" commands taken over regular interval (timestamp shown as cols 1-2) for this one process.

I plotted the vsize and rss from that ps output file (using pandas, in case you're curious), I did see linear growth in the memory usage in several stretches of time. And these stretches did not grow with the same rate. I omitted the first line of the measurement because it is not relevant (vlc was being started).

The smap files are timestamped with the UNIX time and the date/time--the meaning should be clear from the filename. I supplied you three snapshots:

* `smaps-1596468720-20200803T113241.txt`: about 5 minutes into the video playing (still running)
* `smaps-1596510832-20200803T231352.txt`: about 12 hours later (video paused)
* `smaps-1596540657-20200804T073057.txt`: about 20 hours later (video paused)

I did see some new memory regions allocated and it was not clear what they are. But that's all the clue I could gather from my testings. Hope all these help pinpointing the cause of the memory leak.

Here is an example analysis:

~~~
$ diff -y --width=200 <(grep -e '^[0-9a-f]+-[0-9a-f]+' -e 'Dirty' -e Rss smaps-1596468720-20200803T113241.txt) <(grep -e '^[0-9a-f]+-[0-9a-f]+' -e 'Dirty' -e Rss smaps-1596510832-20200803T231352.txt) |less
...

7fc19ec74000-7fc19ed74000 rw-s 00000000 00:1a 264 /i915 (deleted) | 7fc188000000-7fc18b61a000 rw-p 00000000 00:00 0
Rss: 404 kB | Rss: 55400 kB
Shared_Dirty: 0 kB Shared_Dirty: 0 kB
Private_Dirty: 404 kB | Private_Dirty: 55400 kB
7fc19ed74000-7fc19ed88000 rw-s 00000000 00:1a 802 /i915 (deleted) | 7fc18b61a000-7fc18c000000 ---p 00000000 00:00 0
Rss: 4 kB | Rss: 0 kB
Shared_Dirty: 0 kB Shared_Dirty: 0 kB
Private_Dirty: 4 kB | Private_Dirty: 0 kB
                                                                                                   > 7fc190000000-7fc198000000 rw-p 00000000 00:00 0
                                                                                                   > Rss: 131072 kB
                                   ...

[Sebastian Ramacher (s-ramacher)]

What does a run with valgrind say?

[Wirawan Purwanto (wirawan0)]

Plot of RSS and VSIZE over time. Correction: second figure is the zoomed-in version, the time axis format should be: "dd HH:MM".

[Wirawan Purwanto (wirawan0)]

@Sebastian, Here is an initial output of valgrind run--looks like I may need better setting? Please advise / give me suggestion on the switches to use for valgrind. Here is the invocation I did:

$ valgrind --tool=memcheck --leak-check=yes vlc Video.mp4

[Sebastian Ramacher (s-ramacher)]

As suspected, this seems to be an issue with a driver.

[Launchpad Janitor (janitor)]

[Expired for mesa (Ubuntu) because there has been no activity for 60 days.]