GNOME Bugzilla – Bug 665703
mpeg4videoparse: memory leak
Last modified: 2012-01-06 11:41:12 UTC
with the gdp file provided for the bug 665631, using the pipeline: filesrc location=/tmp/test-mp4_1.gdp ! gdpdepay ! mpeg4videoparse ! mp4mux ! filesink location=/tmp/test.mp4 valgrind show the following: ==5249== 9 bytes in 1 blocks are definitely lost in loss record 146 of 2,182 ==5249== at 0x4C28F9F: malloc (vg_replace_malloc.c:236) ==5249== by 0x55BB682: g_malloc (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.3000.0) ==5249== by 0x55D1E4D: g_strdup (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.3000.0) ==5249== by 0x4E7BED0: gst_index_factory_new (gstindexfactory.c:91) ==5249== by 0xB80F813: gst_mem_index_plugin_init (gstmemindex.c:429) ==5249== by 0xB80F105: plugin_init (gstindexers.c:31) ==5249== by 0x4E950A7: gst_plugin_register_func (gstplugin.c:557) ==5249== by 0x4E9633C: gst_plugin_load_file (gstplugin.c:843) ==5249== by 0x4E971C2: gst_plugin_load_by_name (gstplugin.c:1297) ==5249== by 0x4E97BBD: gst_plugin_feature_load (gstpluginfeature.c:111) ==5249== by 0x4E7C06F: gst_index_factory_create (gstindexfactory.c:158) ==5249== by 0x4E7C123: gst_index_factory_make (gstindexfactory.c:192) ==5249== by 0x918E463: gst_base_parse_change_state (gstbaseparse.c:4087) ==5249== by 0x4E71E3B: gst_element_change_state (gstelement.c:2761) ==5249== by 0x4E72791: gst_element_set_state_func (gstelement.c:2717) ==5249== by 0x4E5EE49: gst_bin_change_state_func (gstbin.c:2209) ==5249== by 0x4E92A04: gst_pipeline_change_state (gstpipeline.c:482) ==5249== by 0x4E71E3B: gst_element_change_state (gstelement.c:2761) ==5249== by 0x4E71EBE: gst_element_change_state (gstelement.c:2798) ==5249== by 0x4E72791: gst_element_set_state_func (gstelement.c:2717) ==5249== ==5249== 10 bytes in 1 blocks are definitely lost in loss record 166 of 2,182 ==5249== at 0x4C28F9F: malloc (vg_replace_malloc.c:236) ==5249== by 0x55BB682: g_malloc (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.3000.0) ==5249== by 0x55D1E4D: g_strdup (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.3000.0) ==5249== by 0x4E7BED0: gst_index_factory_new (gstindexfactory.c:91) ==5249== by 0xB8117C2: gst_file_index_plugin_init (gstfileindex.c:974) ==5249== by 0xB80F10F: plugin_init (gstindexers.c:33) ==5249== by 0x4E950A7: gst_plugin_register_func (gstplugin.c:557) ==5249== by 0x4E9633C: gst_plugin_load_file (gstplugin.c:843) ==5249== by 0x4E971C2: gst_plugin_load_by_name (gstplugin.c:1297) ==5249== by 0x4E97BBD: gst_plugin_feature_load (gstpluginfeature.c:111) ==5249== by 0x4E7C06F: gst_index_factory_create (gstindexfactory.c:158) ==5249== by 0x4E7C123: gst_index_factory_make (gstindexfactory.c:192) ==5249== by 0x918E463: gst_base_parse_change_state (gstbaseparse.c:4087) ==5249== by 0x4E71E3B: gst_element_change_state (gstelement.c:2761) ==5249== by 0x4E72791: gst_element_set_state_func (gstelement.c:2717) ==5249== by 0x4E5EE49: gst_bin_change_state_func (gstbin.c:2209) ==5249== by 0x4E92A04: gst_pipeline_change_state (gstpipeline.c:482) ==5249== by 0x4E71E3B: gst_element_change_state (gstelement.c:2761) ==5249== by 0x4E71EBE: gst_element_change_state (gstelement.c:2798) ==5249== by 0x4E72791: gst_element_set_state_func (gstelement.c:2717) ==5249== ==5249== 724 (56 direct, 668 indirect) bytes in 1 blocks are definitely lost in loss record 2,138 of 2,182 ==5249== at 0x4C28F9F: malloc (vg_replace_malloc.c:236) ==5249== by 0x55BB682: g_malloc (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.3000.0) ==5249== by 0x55D0406: g_slice_alloc (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.3000.0) ==5249== by 0x4E6460E: gst_caps_new_empty (gstcaps.c:165) ==5249== by 0x4E6482C: gst_caps_copy (gstcaps.c:310) ==5249== by 0x97EEFB3: gst_mpeg4vparse_parse_frame (gstmpeg4videoparse.c:489) ==5249== by 0x9191573: gst_base_parse_handle_and_push_frame.isra.9 (gstbaseparse.c:1692) ==5249== by 0x91926BC: gst_base_parse_chain (gstbaseparse.c:2493) ==5249== by 0x4E8F159: gst_pad_push (gstpad.c:4710) ==5249== by 0x93D667E: gst_gdp_depay_chain (gstgdpdepay.c:328) ==5249== by 0x4E8F159: gst_pad_push (gstpad.c:4710) ==5249== by 0x91A616B: gst_base_src_loop (gstbasesrc.c:2559) ==5249== by 0x4EB64F3: gst_task_func (gsttask.c:327) ==5249== by 0x55DC7D7: ??? (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.3000.0) ==5249== by 0x55DA2B5: ??? (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.3000.0) ==5249== by 0x586DEFB: start_thread (pthread_create.c:304) ==5249== by 0x5B6489C: clone (clone.S:112)
commit c33b50e00fbfbd6dd21ef922320aa088fad3670f Author: Tim-Philipp Müller <tim.muller@collabora.co.uk> Date: Tue Dec 6 23:52:53 2011 +0000 indexfactory: fix memory leak Introduced by commit bd302bb6 pluginfeature: avoid duplicating feature->name https://bugzilla.gnome.org/show_bug.cgi?id=459466 https://bugzilla.gnome.org/show_bug.cgi?id=665703
the mpeg4videoparse leak doesn't seems fixed: using this file: http://77.43.75.110/temp/test-mp4_1.gdp and this pipeline: filesrc location=/tmp/test-mp4_1.gdp ! gdpdepay ! mpeg4videoparse ! mp4mux ! filesink location=/tmp/test.mp I have: ==5320== LEAK SUMMARY: ==5320== definitely lost: 0 bytes in 0 blocks ==5320== indirectly lost: 240 bytes in 10 blocks ==5320== possibly lost: 322 bytes in 3 blocks ==5320== still reachable: 423,643 bytes in 922 blocks ==5320== suppressed: 125,947 bytes in 1,664 blocks with the last bad release while the current git show this: ==5522== ==5522== HEAP SUMMARY: ==5522== in use at exit: 569,261 bytes in 2,784 blocks ==5522== total heap usage: 139,716 allocs, 136,932 frees, 37,992,286 bytes allocated ==5522== ==5522== Searching for pointers to 2,784 not-freed blocks ==5522== Checked 9,224,768 bytes ==5522== ==5522== 724 (56 direct, 668 indirect) bytes in 1 blocks are definitely lost in loss record 2,136 of 2,182 ==5522== at 0x4C28F9F: malloc (vg_replace_malloc.c:236) ==5522== by 0x55BB682: g_malloc (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.3000.0) ==5522== by 0x55D0406: g_slice_alloc (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.3000.0) ==5522== by 0x4E6466E: gst_caps_new_empty (gstcaps.c:165) ==5522== by 0x4E6488C: gst_caps_copy (gstcaps.c:310) ==5522== by 0x9BF0FB3: gst_mpeg4vparse_parse_frame (gstmpeg4videoparse.c:489) ==5522== by 0x95928B3: gst_base_parse_handle_and_push_frame.isra.9 (gstbaseparse.c:1692) ==5522== by 0x95939FC: gst_base_parse_chain (gstbaseparse.c:2493) ==5522== by 0x4E8F1A9: gst_pad_push (gstpad.c:4710) ==5522== by 0x97D867E: gst_gdp_depay_chain (gstgdpdepay.c:328) ==5522== by 0x4E8F1A9: gst_pad_push (gstpad.c:4710) ==5522== by 0x95A74AB: gst_base_src_loop (gstbasesrc.c:2559) ==5522== by 0x4EB6683: gst_task_func (gsttask.c:327) ==5522== by 0x55DC7D7: ??? (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.3000.0) ==5522== by 0x55DA2B5: ??? (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.3000.0) ==5522== by 0x586DEFB: start_thread (pthread_create.c:304) ==5522== by 0x5B6489C: clone (clone.S:112) ==5522== ==5522== LEAK SUMMARY: ==5522== definitely lost: 56 bytes in 1 blocks ==5522== indirectly lost: 908 bytes in 17 blocks ==5522== possibly lost: 0 bytes in 0 blocks ==5522== still reachable: 39,773 bytes in 809 blocks ==5522== suppressed: 528,524 bytes in 1,957 blocks ==5522== Reachable blocks (those to which a pointer was found) are not shown. ==5522== To see them, rerun with: --leak-check=full --show-reachable=yes
Yes, I only fixed the other leak.
Ah, sorry, I didn't realize there was another one pending.
I did some more tests after gst_caps_unref (caps); in gst_mpeg4vparse_update_src_caps (GstMpeg4VParse * mp4vparse) the caps ref count is always 1 so seems ok but valgrind report a leak ... really strange Valgrind report the leak only with some file/streams such as the file posted, some other file/streams are ok
A ref seems to be held by a gst_caps_replace call when setting the caps on the parser's src pad. I can't pinpoint the culprit though, logs show that the caps always end up being replaced by NULL, which releases the ref. I'll continue looking at it.
And after much hair pulling and dead ends: commit a6d9f6a3ced3c64996623ecbc49e8499cb6a97e0 Author: Vincent Penquerc'h <vincent.penquerch@collabora.co.uk> Date: Thu Jan 5 19:25:33 2012 +0000 isomp4: fix caps leak
Oops, resetting target milestone, the bug in against -bad but the second patch ended up in -good...
this file is really unfortunate, please try this pipeline: filesrc location=test-mp4_1.gdp ! gdpdepay ! mpeg4videoparse ! matroskamux ! filesink location=test.mkv you'll see: ==20008== 16 bytes in 1 blocks are definitely lost in loss record 831 of 2,188 ==20008== at 0x4C28F9F: malloc (vg_replace_malloc.c:236) ==20008== by 0x55BB682: g_malloc (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.3000.0) ==20008== by 0x55D1E4D: g_strdup (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.3000.0) ==20008== by 0xA2FEA9C: gst_matroska_mux_video_pad_setcaps (matroska-mux.c:1108) ==20008== by 0x4E89AEE: gst_pad_set_caps (gstpad.c:2730) ==20008== by 0x4E8B51F: gst_pad_push_data (gstpad.c:4247) ==20008== by 0x4E8F095: gst_pad_push (gstpad.c:4730) ==20008== by 0x9190C1D: gst_base_parse_push_frame (gstbaseparse.c:1993) ==20008== by 0x9191C35: gst_base_parse_handle_and_push_frame.isra.9 (gstbaseparse.c:1770) ==20008== by 0x9192A3C: gst_base_parse_chain (gstbaseparse.c:2493) ==20008== by 0x4E8F1A9: gst_pad_push (gstpad.c:4710) ==20008== by 0x93D767E: gst_gdp_depay_chain (gstgdpdepay.c:328) ==20008== by 0x4E8F1A9: gst_pad_push (gstpad.c:4710) ==20008== by 0x91A64CB: gst_base_src_loop (gstbasesrc.c:2559) ==20008== by 0x4EB66E3: gst_task_func (gsttask.c:327) ==20008== by 0x55DC7D7: ??? (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.3000.0) ==20008== by 0x55DA2B5: ??? (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.3000.0) ==20008== by 0x586DEFB: start_thread (pthread_create.c:304) ==20008== by 0x5B6489C: clone (clone.S:112) ==20008== ==20008== 28 bytes in 1 blocks are definitely lost in loss record 1,082 of 2,188 ==20008== at 0x4C279F2: calloc (vg_replace_malloc.c:467) ==20008== by 0x55BB6E9: g_malloc0 (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.3000.0) ==20008== by 0xA2FE76A: gst_matroska_mux_video_pad_setcaps (matroska-mux.c:1117) ==20008== by 0x4E89AEE: gst_pad_set_caps (gstpad.c:2730) ==20008== by 0x4E8B51F: gst_pad_push_data (gstpad.c:4247) ==20008== by 0x4E8F095: gst_pad_push (gstpad.c:4730) ==20008== by 0x9190C1D: gst_base_parse_push_frame (gstbaseparse.c:1993) ==20008== by 0x9191C35: gst_base_parse_handle_and_push_frame.isra.9 (gstbaseparse.c:1770) ==20008== by 0x9192A3C: gst_base_parse_chain (gstbaseparse.c:2493) ==20008== by 0x4E8F1A9: gst_pad_push (gstpad.c:4710) ==20008== by 0x93D767E: gst_gdp_depay_chain (gstgdpdepay.c:328) ==20008== by 0x4E8F1A9: gst_pad_push (gstpad.c:4710) ==20008== by 0x91A64CB: gst_base_src_loop (gstbasesrc.c:2559) ==20008== by 0x4EB66E3: gst_task_func (gsttask.c:327) ==20008== by 0x55DC7D7: ??? (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.3000.0) ==20008== by 0x55DA2B5: ??? (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.3000.0) ==20008== by 0x586DEFB: start_thread (pthread_create.c:304) ==20008== by 0x5B6489C: clone (clone.S:112)
May I suggest you isolate problems first, and then file individual bugs for each element? e.g. here you should check with gst-launch -v what caps are negotiated on the muxer sink pad, and then do something like ... mpeg4videoparse ! video/xyz...... ! fakesink to narrow down the mpeg4videoparse problem. Anything else should then be filed against the muxer(s) in question.
the problem is in matroskamux, tomorrow I'll open a new bug