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 741943 - glimagesink (or intel_dri) memleak
glimagesink (or intel_dri) memleak
Product: GStreamer
Classification: Platform
Component: gst-plugins-bad
git master
Other Linux
: Normal normal
: 1.5.1
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Reported: 2014-12-24 14:56 UTC by Nicola
Modified: 2015-01-13 07:36 UTC
See Also:
GNOME target: ---
GNOME version: ---

fix some leak in glupload (1.09 KB, patch)
2014-12-25 22:00 UTC, Nicola
committed Details | Review
fix a leak in glcolorconvert (911 bytes, patch)
2014-12-25 22:12 UTC, Nicola
committed Details | Review

Description Nicola 2014-12-24 14:56:27 UTC
running this pipeline:

gst-launch-1.0 -e videotestsrc is-live=true ! glimagesink

show the following in valgrind:

==32030== 1,980 bytes in 44 blocks are definitely lost in loss record 2,053 of 2,092
==32030==    at 0x4C2C080: calloc (in /usr/lib/valgrind/
==32030==    by 0x10D1C9C1: ??? (in /usr/lib/xorg/modules/dri/
==32030==    by 0x10D1CD6C: ??? (in /usr/lib/xorg/modules/dri/
==32030==    by 0x10D1CE33: ??? (in /usr/lib/xorg/modules/dri/
==32030==    by 0x10CD41E2: ??? (in /usr/lib/xorg/modules/dri/
==32030==    by 0x10CE6DF0: ??? (in /usr/lib/xorg/modules/dri/
==32030==    by 0x10CBF339: ??? (in /usr/lib/xorg/modules/dri/
==32030==    by 0x10D0F1C9: ??? (in /usr/lib/xorg/modules/dri/
==32030==    by 0x10CC450D: ??? (in /usr/lib/xorg/modules/dri/
==32030==    by 0x10CC5D7B: ??? (in /usr/lib/xorg/modules/dri/
==32030==    by 0x10CC62E2: ??? (in /usr/lib/xorg/modules/dri/
==32030==    by 0x10CC633E: ??? (in /usr/lib/xorg/modules/dri/
==32030==    by 0x10CC82C1: ??? (in /usr/lib/xorg/modules/dri/
==32030==    by 0x10CC2DBF: ??? (in /usr/lib/xorg/modules/dri/
==32030==    by 0x10D0CBE6: ??? (in /usr/lib/xorg/modules/dri/
==32030==    by 0x10BA5F5E: ??? (in /usr/lib/xorg/modules/dri/
==32030==    by 0x93A23E3: gst_gl_shader_compile (gstglshader.c:481)
==32030==    by 0x93AE7B1: _compile_shader (gstglutils.c:416)
==32030==    by 0x93AB657: _run_message_sync (gstglwindow.c:447)
==32030==    by 0x93B0491: _run_message (gstglwindow_x11.c:690)

I'm not sure if the leak is in i965_dri or in glimagesink,

the same happen with both 1.4.x and git master
Comment 1 Nicola 2014-12-25 21:50:16 UTC
after updating mesa to 10.4 valgrind only show this leak with git master:

==6979== 704 bytes in 1 blocks are definitely lost in loss record 2,010 of 2,073
==6979==    at 0x4C2C080: calloc (in /usr/lib/valgrind/
==6979==    by 0x58F85D1: g_malloc0 (in /usr/lib/
==6979==    by 0x93A990D: _raw_data_upload_new (gstglupload.c:468)
==6979==    by 0x93A9F83: _upload_find_method (gstglupload.c:751)
==6979==    by 0x93AA775: gst_gl_upload_perform_with_buffer (gstglupload.c:831)
==6979==    by 0x915F429: gst_glimage_sink_prepare (gstglimagesink.c:882)
==6979==    by 0x8C9BBED: gst_base_sink_chain_unlocked.isra.25 (gstbasesink.c:3384)
==6979==    by 0x8C9D463: gst_base_sink_chain_main (gstbasesink.c:3547)
==6979==    by 0x4E9E31E: gst_pad_chain_data_unchecked (gstpad.c:3830)
==6979==    by 0x4E9E31E: gst_pad_push_data (gstpad.c:4063)
==6979==    by 0x8CA2EA4: gst_base_src_loop (gstbasesrc.c:2845)
==6979==    by 0x4ECBF70: gst_task_func (gsttask.c:316)
==6979==    by 0x5919F87: ??? (in /usr/lib/
==6979==    by 0x59195F4: ??? (in /usr/lib/
==6979==    by 0x5FCA313: start_thread (in /usr/lib/

so the previous one was in mesa
Comment 2 Nicola 2014-12-25 22:00:58 UTC
Created attachment 293344 [details] [review]
fix some leak in glupload
Comment 3 Nicola 2014-12-25 22:12:39 UTC
Created attachment 293345 [details] [review]
fix a leak in glcolorconvert

after these two patches the only valgrind warning I see is this:

==14266== 408 bytes in 1 blocks are definitely lost in loss record 1,992 of 2,068
==14266==    at 0x4C29F90: malloc (in /usr/lib/valgrind/
==14266==    by 0x400CFEF: _dl_map_object_deps (in /usr/lib/
==14266==    by 0x4013519: dl_open_worker (in /usr/lib/
==14266==    by 0x400F0F3: _dl_catch_error (in /usr/lib/
==14266==    by 0x4012E92: _dl_open (in /usr/lib/
==14266==    by 0x5DC0038: ??? (in /usr/lib/
==14266==    by 0x400F0F3: _dl_catch_error (in /usr/lib/
==14266==    by 0x5DC0608: ??? (in /usr/lib/
==14266==    by 0x5DC00D0: dlopen (in /usr/lib/
==14266==    by 0x56A6981: g_module_open (in /usr/lib/
==14266==    by 0x4EABD03: gst_plugin_load_file (gstplugin.c:736)
==14266==    by 0x4EACADE: gst_plugin_load_by_name (gstplugin.c:1256)
==14266==    by 0x4EAD3EC: gst_plugin_feature_load (gstpluginfeature.c:111)
==14266==    by 0x4E8A018: gst_element_factory_create (gstelementfactory.c:352)
==14266==    by 0x4E8A369: gst_element_factory_make (gstelementfactory.c:446)
==14266==    by 0x4EED0B1: priv_gst_parse_yyparse (grammar.y:687)
==14266==    by 0x4EEE09D: priv_gst_parse_launch (grammar.y:1049)
==14266==    by 0x4EE574E: gst_parse_launch_full (gstparse.c:325)
==14266==    by 0x4EE59D1: gst_parse_launchv_full (gstparse.c:262)
==14266==    by 0x4034A0: main (gst-launch.c:993)

that does not seems a real leak
Comment 4 Nicola 2014-12-25 22:40:42 UTC
please also note that _gl_memory_upload_free  is different from _upload_meta_upload_free and _raw_data_upload_free,

before my patch _gl_memory_upload_free was completly empty, now I free the EGLImageUpload struct but probably also the GstGLUpload pointer inside the struct should be freed (valgrind does not report anything but maybe there can be some use case that generate a leak)
Comment 5 Matthew Waters (ystreet00) 2015-01-13 04:22:24 UTC
Thanks for the patches!

commit 442451a30d33a8eaff22820f7d22d76660c8f1ca
Author: Nicola Murino <>
Date:   Thu Dec 25 23:10:19 2014 +0100

    glcolorconvert: fix memleak

commit 3c6d7757664aab89b18f497e1f675509e482780d
Author: Nicola Murino <>
Date:   Thu Dec 25 22:59:42 2014 +0100

    glupload: fix some memory leaks
Comment 6 Nicola 2015-01-13 07:36:55 UTC
thanks for commiting, so even this change:

is correct

and the GstGLUpload pointer inside GstGlUpload struct is already freed when _gl_memory_upload_free is called in every case (in my quick test is so)