[Bug 721077] totem 3.10.{0,1}: severe memory leak

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=721077
  GStreamer | don't know | 1.x

Bastien Nocera <bugzilla> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEEDINFO                    |NEW
          Component|Movie player                |don't know
            Version|3.10.x                      |1.x
         AssignedTo|totem-general-maint at gnome.b |gstreamer-bugs at lists.freede
                   |ugs                         |sktop.org
            Product|totem                       |GStreamer
   Target Milestone|---                         |HEAD
          QAContact|totem-general-maint at gnome.b |gstreamer-bugs at lists.freede
                   |ugs                         |sktop.org

--- Comment #6 from Bastien Nocera <bugzilla at hadess.net> 2014-01-08 12:39:00 UTC ---
(In reply to comment #5)
> (In reply to comment #4)
> > (In reply to comment #0)
> > > Created an attachment (id=264896)
 --> (https://bugzilla.gnome.org/attachment.cgi?id=264896)
[details]
> > > totem-3.10.1_valgrind_h264.log.xz
> > > 
> > > Both totem 3.10.0 and 3.10.1 use up all memory when playing h264 or xvid videos
> > > on my system. The same files play all right using gst-launch-1.0. Valgrind log
> > > attached.
> > 
> > Does this also happen when you use cluttersink?
> > gst-launch-1.0 playbin uri=file:///path/to/video videosink=cluttersink
> 
> There is no excessive memory usage when playing the files using gst-launch-1.0.

Even with that videosink selected? I doubt it...

> > What video card do you use? If it's an intel one, do you have the GStreamer
> > vaapi plugin installed?
> 
> I use nvidia cards.

The valgrind trace points to a problem with one of GStreamer, libav,
clutter-gst, or even cogl not freeing the decoded video. Reassigning to
GStreamer for now.

==26738== 252,216,187 (227,800 direct, 251,988,387 indirect) bytes in 335
blocks are definitely lost in loss record 29,806 of 29,807
==26738==    at 0x4C2C840: malloc (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==26738==    by 0x65A08B0: g_malloc (in /usr/lib64/libglib-2.0.so.0.3800.2)
==26738==    by 0x65B5A02: g_slice_alloc (in
/usr/lib64/libglib-2.0.so.0.3800.2)
==26738==    by 0x65B5F55: g_slice_alloc0 (in
/usr/lib64/libglib-2.0.so.0.3800.2)
==26738==    by 0x39FF9229: gst_ffmpegviddec_get_buffer (gstavviddec.c:535)
==26738==    by 0x3A924AAB: ff_get_buffer (utils.c:831)
==26738==    by 0x3A8A1DD0: ff_thread_decode_frame (pthread.c:569)
==26738==    by 0x3A92607E: avcodec_decode_video2 (utils.c:2059)
==26738==    by 0x39FF7381: gst_ffmpegviddec_video_frame (gstavviddec.c:1169)
==26738==    by 0x39FF7E1A: gst_ffmpegviddec_frame (gstavviddec.c:1296)
==26738==    by 0x39FF842E: gst_ffmpegviddec_handle_frame (gstavviddec.c:1412)
==26738==    by 0x7807A0F: gst_video_decoder_decode_frame
(gstvideodecoder.c:2760)
==26738== 
==26738== 802,524,222 bytes in 258 blocks are possibly lost in loss record
29,807 of 29,807
==26738==    at 0x4C2C840: malloc (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==26738==    by 0x65A08B0: g_malloc (in /usr/lib64/libglib-2.0.so.0.3800.2)
==26738==    by 0x65B5A02: g_slice_alloc (in
/usr/lib64/libglib-2.0.so.0.3800.2)
==26738==    by 0x7C74670: _sysmem_new_block (gstallocator.c:415)
==26738==    by 0x7C7E655: gst_buffer_new_allocate (gstbuffer.c:668)
==26738==    by 0x78063AA: video_buffer_pool_alloc (gstvideopool.c:195)
==26738==    by 0x7C818F8: do_alloc_buffer.constprop.2 (gstbufferpool.c:272)
==26738==    by 0x7C81BF6: default_acquire_buffer (gstbufferpool.c:995)
==26738==    by 0x7C83075: gst_buffer_pool_acquire_buffer
(gstbufferpool.c:1099)
==26738==    by 0x780F50E: gst_video_decoder_allocate_output_frame
(gstvideodecoder.c:3262)
==26738==    by 0x39FF7AFE: gst_ffmpegviddec_video_frame (gstavviddec.c:1036)
==26738==    by 0x39FF7E1A: gst_ffmpegviddec_frame (gstavviddec.c:1296)

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.