GNOME Bugzilla – Bug 741943
glimagesink (or intel_dri) memleak
Last modified: 2015-01-13 07:36:55 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/vgpreload_memcheck-amd64-linux.so) ==32030== by 0x10D1C9C1: ??? (in /usr/lib/xorg/modules/dri/i965_dri.so) ==32030== by 0x10D1CD6C: ??? (in /usr/lib/xorg/modules/dri/i965_dri.so) ==32030== by 0x10D1CE33: ??? (in /usr/lib/xorg/modules/dri/i965_dri.so) ==32030== by 0x10CD41E2: ??? (in /usr/lib/xorg/modules/dri/i965_dri.so) ==32030== by 0x10CE6DF0: ??? (in /usr/lib/xorg/modules/dri/i965_dri.so) ==32030== by 0x10CBF339: ??? (in /usr/lib/xorg/modules/dri/i965_dri.so) ==32030== by 0x10D0F1C9: ??? (in /usr/lib/xorg/modules/dri/i965_dri.so) ==32030== by 0x10CC450D: ??? (in /usr/lib/xorg/modules/dri/i965_dri.so) ==32030== by 0x10CC5D7B: ??? (in /usr/lib/xorg/modules/dri/i965_dri.so) ==32030== by 0x10CC62E2: ??? (in /usr/lib/xorg/modules/dri/i965_dri.so) ==32030== by 0x10CC633E: ??? (in /usr/lib/xorg/modules/dri/i965_dri.so) ==32030== by 0x10CC82C1: ??? (in /usr/lib/xorg/modules/dri/i965_dri.so) ==32030== by 0x10CC2DBF: ??? (in /usr/lib/xorg/modules/dri/i965_dri.so) ==32030== by 0x10D0CBE6: ??? (in /usr/lib/xorg/modules/dri/i965_dri.so) ==32030== by 0x10BA5F5E: ??? (in /usr/lib/xorg/modules/dri/i965_dri.so) ==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
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/vgpreload_memcheck-amd64-linux.so) ==6979== by 0x58F85D1: g_malloc0 (in /usr/lib/libglib-2.0.so.0.4200.1) ==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/libglib-2.0.so.0.4200.1) ==6979== by 0x59195F4: ??? (in /usr/lib/libglib-2.0.so.0.4200.1) ==6979== by 0x5FCA313: start_thread (in /usr/lib/libpthread-2.20.so) so the previous one was in mesa
Created attachment 293344 [details] [review] fix some leak in glupload
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/vgpreload_memcheck-amd64-linux.so) ==14266== by 0x400CFEF: _dl_map_object_deps (in /usr/lib/ld-2.20.so) ==14266== by 0x4013519: dl_open_worker (in /usr/lib/ld-2.20.so) ==14266== by 0x400F0F3: _dl_catch_error (in /usr/lib/ld-2.20.so) ==14266== by 0x4012E92: _dl_open (in /usr/lib/ld-2.20.so) ==14266== by 0x5DC0038: ??? (in /usr/lib/libdl-2.20.so) ==14266== by 0x400F0F3: _dl_catch_error (in /usr/lib/ld-2.20.so) ==14266== by 0x5DC0608: ??? (in /usr/lib/libdl-2.20.so) ==14266== by 0x5DC00D0: dlopen (in /usr/lib/libdl-2.20.so) ==14266== by 0x56A6981: g_module_open (in /usr/lib/libgmodule-2.0.so.0.4200.1) ==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
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)
Thanks for the patches! commit 442451a30d33a8eaff22820f7d22d76660c8f1ca Author: Nicola Murino <nicola.murino@gmail.com> Date: Thu Dec 25 23:10:19 2014 +0100 glcolorconvert: fix memleak https://bugzilla.gnome.org/show_bug.cgi?id=741943 commit 3c6d7757664aab89b18f497e1f675509e482780d Author: Nicola Murino <nicola.murino@gmail.com> Date: Thu Dec 25 22:59:42 2014 +0100 glupload: fix some memory leaks https://bugzilla.gnome.org/show_bug.cgi?id=741943
thanks for commiting, so even this change: http://cgit.freedesktop.org/gstreamer/gst-plugins-bad/tree/gst-libs/gst/gl/gstglupload.c?id=3c6d7757664aab89b18f497e1f675509e482780d#n183 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)