After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 708335 - Totem leaking memory _very_ fast
Totem leaking memory _very_ fast
Status: RESOLVED DUPLICATE of bug 721077
Product: clutter-gst
Classification: Other
Component: general
unspecified
Other Linux
: Normal major
: ---
Assigned To: clutter-gst-maint
clutter-gst-maint
Depends on:
Blocks:
 
 
Reported: 2013-09-18 23:14 UTC by J.A. Magallón
Modified: 2014-01-10 17:04 UTC
See Also:
GNOME target: ---
GNOME version: ---


Description J.A. Magallón 2013-09-18 23:14:47 UTC 
I noticed that after playing somw video during long time, my box got very slow.
I trached to to totem:

werewolf:~> top -b -d 10 | grep totem
11271 S magallon  2.0 2082m 161m   12 1.2g  56m 1.9g 1   22   0:02 totem
11271 S magallon  3.0 2210m 241m   12 1.4g  57m 1.9g 3   11   0:03 totem
11271 S magallon  4.0 2274m 322m   12 1.4g  57m 1.9g 0   11   0:04 totem
11271 S magallon  5.0 2338m 402m   12 1.5g  57m 1.9g 2   10   0:05 totem
11271 S magallon  6.0 2402m 483m   12 1.5g  58m 1.9g 1   11   0:06 totem
11271 S magallon  7.1 2530m 563m   12 1.7g  58m 1.9g 3   11   0:07 totem
11271 S magallon  8.1 2594m 644m   12 1.7g  58m 1.9g 0   11   0:08 totem
11271 S magallon  9.1 2658m 724m   12 1.8g  58m 1.9g 1   11   0:09 totem
11271 S magallon 10.1 2722m 806m   12 1.9g  58m 1.9g 1   11   0:11 totem
11271 S magallon 11.1 2850m 887m   12 2.0g  58m 1.9g 0   12   0:12 totem
11271 S magallon 12.1 2914m 968m   12 2.0g  58m 1.9g 3   12   0:13 totem
11271 S magallon 13.2 2978m 1.0g   12 2.1g  58m 1.9g 1   18   0:15 totem

That is a couple minutes.
After half a movie it can bring the box to his knees. It looks like some
serious leak.

I would not blame GStreamer itself, because parole also uses gst-1.0 and
does not seem to leak so much:

werewolf:~> top -b -d 10 | grep parole
18447 S magallon  1.0 1794m  76m  340 1.2g  36m 1.7g 3   14   0:01 parole
18447 S magallon  1.0 1794m  77m  340 1.2g  37m 1.7g 0    7   0:02 parole
18447 S magallon  1.0 1794m  78m  340 1.2g  38m 1.7g 1    6   0:02 parole
18447 S magallon  1.0 1794m  78m  340 1.2g  38m 1.7g 0    6   0:03 parole
18447 S magallon  1.0 1794m  78m  340 1.2g  38m 1.7g 1    6   0:03 parole
18447 S magallon  1.0 1794m  78m  340 1.2g  38m 1.7g 1    6   0:04 parole
18447 S magallon  1.0 1794m  78m  340 1.2g  38m 1.7g 1    6   0:05 parole
18447 S magallon  1.0 1794m  79m  340 1.2g  38m 1.7g 0    6   0:05 parole
18447 S magallon  1.0 1794m  79m  340 1.2g  38m 1.7g 1    6   0:06 parole
18447 S magallon  1.0 1794m  79m  340 1.2g  38m 1.7g 1    7   0:07 parole
18447 S magallon  1.0 1794m  79m  340 1.2g  38m 1.7g 0    7   0:07 parole
18447 S magallon  1.0 1794m  79m  340 1.2g  38m 1.7g 1    7   0:08 parole 

Or with gst-launch-1.0 playbin uri=file://$PWD/video.avi

werewolf:~> top -b -d 10 | grep gst
28235 S magallon  0.5 1220m  39m   28 881m  18m 1.2g 0    6   0:00 gst-launch-1.0
28235 S magallon  0.5 1220m  39m   28 881m  19m 1.2g 1    6   0:01 gst-launch-1.0
28235 S magallon  0.5 1220m  39m   28 881m  19m 1.2g 1    6   0:01 gst-launch-1.0
28235 S magallon  0.5 1220m  40m   28 881m  19m 1.2g 0    6   0:02 gst-launch-1.0
28235 S magallon  0.5 1220m  40m   28 881m  19m 1.2g 2    6   0:03 gst-launch-1.0
28235 S magallon  0.5 1220m  40m   28 881m  19m 1.2g 2    6   0:03 gst-launch-1.0
28235 S magallon  0.5 1220m  40m   28 881m  19m 1.2g 3    6   0:04 gst-launch-1.0

Totem uses double the memory as parole and leaks very fast...

Any ideas ?
Comment 1 Bastien Nocera 2013-09-18 23:26:16 UTC 
(In reply to comment #0)
> Or with gst-launch-1.0 playbin uri=file://$PWD/video.avi

Try with:
gst-launch-1.0 playbin uri=file://$PWD/video.avi video-sink=cluttersink
Comment 2 J.A. Magallón 2013-09-19 12:51:42 UTC 
Good catch...

This is the run with standard sink (gst-launch-1.0 playbin uri=file://$PWD/video.avi):

pandora:~> top -b -d 10 -n 10 | grep gst
 1902 S magallon  0.9 1207m  35m   28 882m  15m 1.1g 1    4   0:00 gst-launch-1.0                                          
 1902 S magallon  0.9 1207m  36m   28 882m  15m 1.1g 2    4   0:00 gst-launch-1.0                                          
 1902 S magallon  0.9 1207m  35m   28 882m  15m 1.1g 1    3   0:01 gst-launch-1.0                                          
 1902 S magallon  0.9 1207m  36m   28 882m  15m 1.1g 1    2   0:01 gst-launch-1.0                                          
 1902 S magallon  0.9 1207m  36m   28 882m  15m 1.1g 1    4   0:01 gst-launch-1.0                                          
 1902 S magallon  0.9 1207m  36m   28 882m  15m 1.1g 2    4   0:02 gst-launch-1.0                                          
 1902 S magallon  0.9 1207m  35m   28 882m  15m 1.1g 1    4   0:02 gst-launch-1.0                                          
 1902 S magallon  0.9 1207m  36m   28 882m  15m 1.1g 2    4   0:02 gst-launch-1.0                                          
 1902 S magallon  0.9 1207m  36m   28 882m  15m 1.1g 1    3   0:03 gst-launch-1.0 

And this with clutter (gst-launch-1.0 playbin uri=file://$PWD/video.avi video-sink=cluttersink):

pandora:~> top -b -d 10 -n 10 | grep gst
 2196 S magallon  3.0 1330m 116m   28 887m  15m 1.2g 0    7   0:00 gst-launch-1.0                                          
 2196 S magallon  5.0 1394m 192m   28 951m  15m 1.2g 1    6   0:01 gst-launch-1.0                                          
 2196 S magallon  7.0 1458m 269m   28 1.0g  16m 1.2g 0    5   0:01 gst-launch-1.0                                          
 2196 S magallon  9.0 1522m 346m   28 1.1g  16m 1.1g 1    5   0:02 gst-launch-1.0                                          
 2196 S magallon 11.1 1586m 424m   28 1.1g  16m 1.1g 1    6   0:02 gst-launch-1.0                                          
 2196 S magallon 13.1 1714m 504m   28 1.2g  16m 1.2g 1    7   0:03 gst-launch-1.0                                          
 2196 S magallon 15.2 1778m 582m   28 1.3g  16m 1.2g 1    6   0:04 gst-launch-1.0                                          
 2196 S magallon 17.2 1842m 660m   28 1.4g  16m 1.2g 1    6   0:04 gst-launch-1.0                                          
 2196 S magallon 19.2 1906m 736m   28 1.4g  16m 1.1g 1    5   0:05 gst-launch-1.0

So clutter is leakinnnn....;)

Where can I configure the default video sink systemwide, till the bug is solved ?
TIA
Comment 3 Bastien Nocera 2013-09-19 13:12:07 UTC 
The video sink isn't changeable. Will reassign to clutter-gst to check out what this problem could be (likely a bug in Mesa I would think).
Comment 4 Lionel Landwerlin 2013-09-19 14:44:29 UTC 
What version of ClutterGst are we talking about?
I can't reproduce the leak with 2.0.6 or 2.0.8.
Comment 5 J.A. Magallón 2013-09-19 15:02:16 UTC 
This is 2.0.8
Comment 6 J.A. Magallón 2013-09-25 07:19:21 UTC 
Any news ?
I don't think it is a problem in Mesa, because it happens both on boxes running nVidia driver and on Intel graphics ones...
Comment 7 Lionel Landwerlin 2013-09-25 09:00:56 UTC 
I'm running 2.0.8 on Intel with Mesa 9.2 and I can't see any leak.
What's you version of mesa?
Comment 8 Lionel Landwerlin 2013-09-25 09:03:55 UTC 
What about the GStreamer version?
Is Gstreamer-vaapi installed too?
Comment 9 J.A. Magallón 2013-09-30 22:05:32 UTC 
Sorry for the delay, I'm not getting the CCs from the bug, and I'm on the CC list...

Distro is Mageia Cauldron (unstable). Current versions of software are these:

GStreamer   -> 1.2.0
gst-vaapi   -> there is no vaapi for gst-1.2 (only in old 0.10)
clutter     -> 1.16.0
clutter-gst -> 2.0.8
mesa        -> 9.2.0-rc1

The only curious thing I see is that mesa is still rc1, and final 9.2
is already out. Perhaps it is really a bug in Mesa and is corrected
between rc1 and final.

I can ask to my distro mantainers to update Mesa to final, and re-check.
But I don't see how this can affect to a box running with propietary
nvidia drivers, unless some weird mix is happening...
Comment 10 J.A. Magallón 2013-10-06 21:30:15 UTC 
we have now an updated Mesa to 9.2.1, and it keeps the same.
The cluttter sink keeps leaking memory:

werewolf:~/torrent> top -b -d 10 -n 10 | grep gst
 9115 S magallon  5.2 1693m 418m   28 1.2g  44m 1.2g 0   10   0:04 gst-launch-1.0                    
 9115 S magallon  6.2 1757m 498m   28 1.2g  44m 1.2g 3   10   0:05 gst-launch-1.0                    
 9115 S magallon  7.3 1821m 579m   28 1.3g  44m 1.2g 2   10   0:06 gst-launch-1.0                    
 9115 S magallon  8.3 1949m 660m   28 1.4g  44m 1.3g 2   10   0:07 gst-launch-1.0                    
 9115 S magallon  9.3 2013m 740m   28 1.5g  44m 1.2g 3   10   0:08 gst-launch-1.0
 9115 S magallon 10.3 2077m 822m   28 1.6g  44m 1.2g 1   11   0:09 gst-launch-1.0
 9115 S magallon 11.3 2141m 903m   28 1.6g  44m 1.2g 1   11   0:10 gst-launch-1.0
 9115 S magallon 12.3 2269m 984m   28 1.7g  44m 1.3g 1   11   0:11 gst-launch-1.0
 9115 S magallon 13.4 2333m 1.0g   28 1.8g  44m 1.2g 1   11   0:12 gst-launch-1.0
 9115 S magallon 14.4 2397m 1.1g   28 1.9g  44m 1.2g 0   11   0:13 gst-launch-1.0
Comment 11 J.A. Magallón 2013-10-06 23:06:46 UTC 
I have tried to run these through valgrind:

valgrind --leak-check=full gst-launch-1.0 playbin uri=file://$PWD/small.mp4 video-sink=XXXXXXX

with this video sample (a small 5 sec clip):

http://techslides.com/sample-webm-ogg-and-mp4-video-files-for-html5/small.mp4

With xvimagesink, the biggest leak is this:

==10493== 449,424 bytes in 1 blocks are definitely lost in loss record 4,849 of 4,849
==10493==    at 0x4C28765: memalign (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==10493==    by 0x4C2882A: posix_memalign (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==10493==    by 0xF171C2C: av_malloc (in /usr/lib64/libavutil.so.52.38.100)
==10493==    by 0xF171DAD: av_mallocz (in /usr/lib64/libavutil.so.52.38.100)
==10493==    by 0xE608AD7: avcodec_get_context_defaults3 (in /usr/lib64/libavcodec.so.55.18.102)
==10493==    by 0xE608B45: avcodec_alloc_context3 (in /usr/lib64/libavcodec.so.55.18.102)
==10493==    by 0xD8F53B2: ??? (in /usr/lib64/gstreamer-1.0/libgstlibav.so)
==10493==    by 0x516313A: g_type_create_instance (in /usr/lib64/libgobject-2.0.so.0.3800.0)
==10493==    by 0x51475E4: ??? (in /usr/lib64/libgobject-2.0.so.0.3800.0)
==10493==    by 0x51493DC: g_object_newv (in /usr/lib64/libgobject-2.0.so.0.3800.0)
==10493==    by 0x4E7E869: gst_element_factory_create (in /usr/lib64/libgstreamer-1.0.so.0.200.0)
==10493==    by 0x6FE2883: ??? (in /usr/lib64/gstreamer-1.0/libgstplayback.so)
==10493== 
==10493== LEAK SUMMARY:
==10493==    definitely lost: 467,111 bytes in 25 blocks
==10493==    indirectly lost: 3,448 bytes in 15 blocks
==10493==      possibly lost: 26,938 bytes in 515 blocks

With cluttersink:

==10530== 449,424 bytes in 1 blocks are definitely lost in loss record 6,174 of 6,177
==10530==    at 0x4C28765: memalign (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==10530==    by 0x4C2882A: posix_memalign (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==10530==    by 0x19DCCC2C: av_malloc (in /usr/lib64/libavutil.so.52.38.100)
==10530==    by 0x19DCCDAD: av_mallocz (in /usr/lib64/libavutil.so.52.38.100)
==10530==    by 0x19263AD7: avcodec_get_context_defaults3 (in /usr/lib64/libavcodec.so.55.18.102)
==10530==    by 0x19263B45: avcodec_alloc_context3 (in /usr/lib64/libavcodec.so.55.18.102)
==10530==    by 0x185503B2: ??? (in /usr/lib64/gstreamer-1.0/libgstlibav.so)
==10530==    by 0x516313A: g_type_create_instance (in /usr/lib64/libgobject-2.0.so.0.3800.0)
==10530==    by 0x51475E4: ??? (in /usr/lib64/libgobject-2.0.so.0.3800.0)
==10530==    by 0x51493DC: g_object_newv (in /usr/lib64/libgobject-2.0.so.0.3800.0)
==10530==    by 0x4E7E869: gst_element_factory_create (in /usr/lib64/libgstreamer-1.0.so.0.200.0)
==10530==    by 0x6FE2883: ??? (in /usr/lib64/gstreamer-1.0/libgstplayback.so)
==10530== 
==10530== 3,496,467 bytes in 13 blocks are possibly lost in loss record 6,175 of 6,177
==10530==    at 0x4C26699: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==10530==    by 0x53D0C30: g_malloc (in /usr/lib64/libglib-2.0.so.0.3800.0)
==10530==    by 0x53E67CD: g_slice_alloc (in /usr/lib64/libglib-2.0.so.0.3800.0)
==10530==    by 0x4E5BADC: ??? (in /usr/lib64/libgstreamer-1.0.so.0.200.0)
==10530==    by 0x4E657B1: gst_buffer_new_allocate (in /usr/lib64/libgstreamer-1.0.so.0.200.0)
==10530==    by 0x76A86AC: ??? (in /usr/lib64/libgstvideo-1.0.so.0.200.0)
==10530==    by 0x4E68693: ??? (in /usr/lib64/libgstreamer-1.0.so.0.200.0)
==10530==    by 0x4E68A35: ??? (in /usr/lib64/libgstreamer-1.0.so.0.200.0)
==10530==    by 0x4E69D41: gst_buffer_pool_acquire_buffer (in /usr/lib64/libgstreamer-1.0.so.0.200.0)
==10530==    by 0x76B130E: gst_video_decoder_allocate_output_frame (in /usr/lib64/libgstvideo-1.0.so.0.200.0)
==10530==    by 0x185524EE: ??? (in /usr/lib64/gstreamer-1.0/libgstlibav.so)
==10530==    by 0x185527F7: ??? (in /usr/lib64/gstreamer-1.0/libgstlibav.so)
==10530== 
==10530== 41,207,216 (112,880 direct, 41,094,336 indirect) bytes in 166 blocks are definitely lost in loss record 6,177 of 6,177
==10530==    at 0x4C26699: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==10530==    by 0x53D0C30: g_malloc (in /usr/lib64/libglib-2.0.so.0.3800.0)
==10530==    by 0x53E67CD: g_slice_alloc (in /usr/lib64/libglib-2.0.so.0.3800.0)
==10530==    by 0x53E6D0D: g_slice_alloc0 (in /usr/lib64/libglib-2.0.so.0.3800.0)
==10530==    by 0x18553989: ??? (in /usr/lib64/gstreamer-1.0/libgstlibav.so)
==10530==    by 0x19319F21: ??? (in /usr/lib64/libavcodec.so.55.18.102)
==10530==    by 0x19279999: ??? (in /usr/lib64/libavcodec.so.55.18.102)
==10530==    by 0x1931B3CD: avcodec_decode_video2 (in /usr/lib64/libavcodec.so.55.18.102)
==10530==    by 0x18551D71: ??? (in /usr/lib64/gstreamer-1.0/libgstlibav.so)
==10530==    by 0x185527F7: ??? (in /usr/lib64/gstreamer-1.0/libgstlibav.so)
==10530==    by 0x18552E90: ??? (in /usr/lib64/gstreamer-1.0/libgstlibav.so)
==10530==    by 0x76AA618: ??? (in /usr/lib64/libgstvideo-1.0.so.0.200.0)
==10530== 
==10530== LEAK SUMMARY:
==10530==    definitely lost: 854,443 bytes in 197 blocks
==10530==    indirectly lost: 41,098,191 bytes in 860 blocks
==10530==      possibly lost: 3,528,017 bytes in 617 blocks

With my original video, after 15-20 seconds:

==10754== 11,241,726 bytes in 34 blocks are possibly lost in loss record 6,479 of 6,482
==10754==    at 0x4C26699: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==10754==    by 0x53D0C30: g_malloc (in /usr/lib64/libglib-2.0.so.0.3800.0)
==10754==    by 0x53E67CD: g_slice_alloc (in /usr/lib64/libglib-2.0.so.0.3800.0)
==10754==    by 0x4E5BADC: ??? (in /usr/lib64/libgstreamer-1.0.so.0.200.0)
==10754==    by 0x4E657B1: gst_buffer_new_allocate (in /usr/lib64/libgstreamer-1.0.so.0.200.0)
==10754==    by 0x76A86AC: ??? (in /usr/lib64/libgstvideo-1.0.so.0.200.0)
==10754==    by 0x4E68693: ??? (in /usr/lib64/libgstreamer-1.0.so.0.200.0)
==10754==    by 0x4E68A35: ??? (in /usr/lib64/libgstreamer-1.0.so.0.200.0)
==10754==    by 0x4E69D41: gst_buffer_pool_acquire_buffer (in /usr/lib64/libgstreamer-1.0.so.0.200.0)
==10754==    by 0x76B130E: gst_video_decoder_allocate_output_frame (in /usr/lib64/libgstvideo-1.0.so.0.200.0)
==10754==    by 0x211A94EE: ??? (in /usr/lib64/gstreamer-1.0/libgstlibav.so)
==10754==    by 0x211A97F7: ??? (in /usr/lib64/gstreamer-1.0/libgstlibav.so)
==10754== 
==10754== 69,745,111 (151,640 direct, 69,593,471 indirect) bytes in 223 blocks are definitely lost in loss record 6,480 of 6,482
==10754==    at 0x4C26699: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==10754==    by 0x53D0C30: g_malloc (in /usr/lib64/libglib-2.0.so.0.3800.0)
==10754==    by 0x53E67CD: g_slice_alloc (in /usr/lib64/libglib-2.0.so.0.3800.0)
==10754==    by 0x53E6D0D: g_slice_alloc0 (in /usr/lib64/libglib-2.0.so.0.3800.0)
==10754==    by 0x211AA989: ??? (in /usr/lib64/gstreamer-1.0/libgstlibav.so)
==10754==    by 0x21B70F21: ??? (in /usr/lib64/libavcodec.so.55.18.102)
==10754==    by 0x21AD0999: ??? (in /usr/lib64/libavcodec.so.55.18.102)
==10754==    by 0x21B723CD: avcodec_decode_video2 (in /usr/lib64/libavcodec.so.55.18.102)
==10754==    by 0x211A8D71: ??? (in /usr/lib64/gstreamer-1.0/libgstlibav.so)
==10754==    by 0x211A97F7: ??? (in /usr/lib64/gstreamer-1.0/libgstlibav.so)
==10754==    by 0x211A9E90: ??? (in /usr/lib64/gstreamer-1.0/libgstlibav.so)
==10754==    by 0x76AA618: ??? (in /usr/lib64/libgstvideo-1.0.so.0.200.0)
==10754== 
==10754== 95,701,910 (210,800 direct, 95,491,110 indirect) bytes in 310 blocks are definitely lost in loss record 6,481 of 6,482
==10754==    at 0x4C26699: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==10754==    by 0x53D0C30: g_malloc (in /usr/lib64/libglib-2.0.so.0.3800.0)
==10754==    by 0x53E67CD: g_slice_alloc (in /usr/lib64/libglib-2.0.so.0.3800.0)
==10754==    by 0x53E6D0D: g_slice_alloc0 (in /usr/lib64/libglib-2.0.so.0.3800.0)
==10754==    by 0x211AA989: ??? (in /usr/lib64/gstreamer-1.0/libgstlibav.so)
==10754==    by 0x21B70ECC: ??? (in /usr/lib64/libavcodec.so.55.18.102)
==10754==    by 0x21AD0999: ??? (in /usr/lib64/libavcodec.so.55.18.102)
==10754==    by 0x21B723CD: avcodec_decode_video2 (in /usr/lib64/libavcodec.so.55.18.102)
==10754==    by 0x211A8D71: ??? (in /usr/lib64/gstreamer-1.0/libgstlibav.so)
==10754==    by 0x211A97F7: ??? (in /usr/lib64/gstreamer-1.0/libgstlibav.so)
==10754==    by 0x211A9E90: ??? (in /usr/lib64/gstreamer-1.0/libgstlibav.so)
==10754==    by 0x76AA618: ??? (in /usr/lib64/libgstvideo-1.0.so.0.200.0)
==10754== 
==10754== LEAK SUMMARY:
==10754==    definitely lost: 668,787 bytes in 565 blocks
==10754==    indirectly lost: 165,088,580 bytes in 2,827 blocks
==10754==      possibly lost: 11,329,971 bytes in 1,919 blocks

Perhaps it is useful...
Comment 12 Götz Waschk 2014-01-10 16:52:23 UTC 
dupe of bug #721077 ?
Comment 13 Lionel Landwerlin 2014-01-10 17:03:11 UTC 
It would explain why only few people reproduce it.
Comment 14 Lionel Landwerlin 2014-01-10 17:04:04 UTC 
Looks like the same source of allocation. Dup!

*** This bug has been marked as a duplicate of bug 721077 ***