GNOME Bugzilla – Bug 761070
h265parse: Fix buffer memory leak
Last modified: 2016-04-14 17:43:04 UTC
While setting caps, codec_data buffer is mapped, but not being unmapped leading to memory leaks.
Created attachment 319644 [details] [review] fix buffer leak Fix for the below leak ==31311== 202 bytes in 1 blocks are definitely lost in loss record 3,929 of 4,058 ==31311== at 0x402C17C: malloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so) ==31311== by 0x425EBE2: g_malloc (in /lib/i386-linux-gnu/libglib-2.0.so.0.4002.0) ==31311== by 0x4275281: g_slice_alloc (in /lib/i386-linux-gnu/libglib-2.0.so.0.4002.0) ==31311== by 0x409DF03: _sysmem_new_block (gstallocator.c:414) ==31311== by 0x409E5DA: gst_allocator_alloc (gstallocator.c:311) ==31311== by 0x40AA405: gst_buffer_new_allocate (gstbuffer.c:755) ==31311== by 0x718A63C: qtdemux_parse_tree (qtdemux.c:9151) ==31311== by 0x718FBA8: gst_qtdemux_loop_state_header (qtdemux.c:3885) ==31311== by 0x7193FB0: gst_qtdemux_loop (qtdemux.c:5287) ==31311== by 0x411BC68: gst_task_func (gsttask.c:331) ==31311== by 0x411CE0E: default_func (gsttaskpool.c:68) ==31311== by 0x4280404: ??? (in /lib/i386-linux-gnu/libglib-2.0.so.0.4002.0) ==31311== by 0x427F9A9: ??? (in /lib/i386-linux-gnu/libglib-2.0.so.0.4002.0) ==31311== by 0x4324F6F: start_thread (pthread_create.c:312) ==31311== by 0x4426BED: clone (clone.S:129)
Created attachment 319656 [details] [review] fix buffer leak when sps is not present. While just reviewing the code of h265parse, found another place where there is a potential leak. When SPS is not present, there is no need to allocate buffer and map it. So moving the check for SPS above the buffer allocation.
commit e389211aa54f2b1da9df9dbe80f8624ba5e045db Author: Vineeth TM <vineeth.tm@samsung.com> Date: Mon Jan 25 13:33:09 2016 +0900 h265parse: Fix buffer leak when sps is not present When sps data is NULL, the buffer allocated and mapped is not being freed. In this scenario there is no need to allocate the buffer as we are supposed to return NULL. https://bugzilla.gnome.org/show_bug.cgi?id=761070 commit 6a35a4018e4274ce1965054161e92291d19f6291 Author: Vineeth TM <vineeth.tm@samsung.com> Date: Mon Jan 25 12:05:12 2016 +0900 h265parse: Fix buffer memory leak. While setting caps, codec_data buffer is mapped, but not being unmapped leading to memory leaks. https://bugzilla.gnome.org/show_bug.cgi?id=761070
Merged to 1.6: commit 6520a2c6866203d0e141ef7987de10cd6fc38b8f Author: Vineeth TM <vineeth.tm@samsung.com> Date: Mon Jan 25 13:33:09 2016 +0900 h265parse: Fix buffer leak when sps is not present When sps data is NULL, the buffer allocated and mapped is not being freed. In this scenario there is no need to allocate the buffer as we are supposed to return NULL. https://bugzilla.gnome.org/show_bug.cgi?id=761070 commit 9bc4dfd004316f6ff4d6552c9c292537e608b7a0 Author: Vineeth TM <vineeth.tm@samsung.com> Date: Mon Jan 25 12:05:12 2016 +0900 h265parse: Fix buffer memory leak. While setting caps, codec_data buffer is mapped, but not being unmapped leading to memory leaks. https://bugzilla.gnome.org/show_bug.cgi?id=761070