Memory leak when parsing WAV files that includes "JUNK"
Memory leak when parsing WAV files that includes "JUNK"
So I have found that running the included WAV file I am finding a memory leak (chime_initiated_call). I have tried narrowing it down as much as possible however I have problem following why the code is taking the path it is taking, also understanding the WAV format is not clear, but lets discuss what I have found.
First the stack trace of the memory leak:
Indirect leak of 10080 byte(s) in 36 object(s) allocated from:
#0 0x7f88747dbc in \__interceptor_malloc r0/libsanitizer/asan/asan_malloc_linux.cpp:69 (discriminator 2)
#1 0x7f8859b3b4 in g_malloc r0/glib/gmem.c:130
#2 0x7f885b4874 in g_slice_alloc r0/glib/gslice.c:1074
#3 0x7f8811af84 in gst_buffer_new r0/gst/gstbuffer.c:863
#4 0x7f8811ce70 in gst_buffer_new_allocate r0/gst/gstbuffer.c:908
#5 0x7f875617dc in gst_base_src_default_alloc r0/libs/gst/base/gstbasesrc.c:1546
#6 0x7f8755f954 in gst_base_src_default_create r0/libs/gst/base/gstbasesrc.c:1592
#7 0x7f8755cc60 in gst_base_src_get_range r0/libs/gst/base/gstbasesrc.c:2592 (discriminator 7)
#8 0x7f8755f738 in gst_base_src_getrange r0/libs/gst/base/gstbasesrc.c:2793
#9 0x7f88197214 in gst_pad_get_range_unchecked r0/gst/gstpad.c:4948 (discriminator 7)
#10 0x7f881a5e0c in gst_pad_pull_range r0/gst/gstpad.c:5193
#11 0x7f8816976c in gst_proxy_pad_getrange_default r0/gst/gstghostpad.c:185 (discriminator 2)
#12 0x7f88197214 in gst_pad_get_range_unchecked r0/gst/gstpad.c:4948 (discriminator 7)
#13 0x7f881a5e0c in gst_pad_pull_range r0/gst/gstpad.c:5193
#14 0x7f88197214 in gst_pad_get_range_unchecked r0/gst/gstpad.c:4948 (discriminator 7)
#15 0x7f881a5e0c in gst_pad_pull_range r0/gst/gstpad.c:5193
#16 0x7f85b1756c in gst_wavparse_stream_headers r0/gst/wavparse/gstwavparse.c:1555
#17 0x7f85b1a61c in gst_wavparse_loop r0/gst/wavparse/gstwavparse.c:2252 (discriminator 7)
#18 0x7f88201678 in gst_task_func r0/gst/gsttask.c:384
#19 0x7f885c1b44 in g_thread_pool_thread_proxy r0/glib/gthreadpool.c:352
#20 0x7f885c0eb4 in g_thread_proxy r0/glib/gthread.c:831
#21 0x7f87d7eea0 in start_thread r1/nptl/pthread_create.c:444
#22 0x7f87de59d8 in thread_start r1/misc/../sysdeps/unix/sysv/linux/aarch64/clone.S:79
Indirect leak of 7308 byte(s) in 36 object(s) allocated from:
#0 0x7f88747dbc in \__interceptor_malloc r0/libsanitizer/asan/asan_malloc_linux.cpp:69 (discriminator 2)
#1 0x7f8859b3b4 in g_malloc r0/glib/gmem.c:130
#2 0x7f885b4874 in g_slice_alloc r0/glib/gslice.c:1074
#3 0x7f88107f5c in \_sysmem_new_block r0/gst/gstallocator.c:437
#4 0x7f8811ce64 in gst_buffer_new_allocate r0/gst/gstbuffer.c:901
#5 0x7f875617dc in gst_base_src_default_alloc r0/libs/gst/base/gstbasesrc.c:1546
#6 0x7f8755f954 in gst_base_src_default_create r0/libs/gst/base/gstbasesrc.c:1592
#7 0x7f8755cc60 in gst_base_src_get_range r0/libs/gst/base/gstbasesrc.c:2592 (discriminator 7)
#8 0x7f8755f738 in gst_base_src_getrange r0/libs/gst/base/gstbasesrc.c:2793
#9 0x7f88197214 in gst_pad_get_range_unchecked r0/gst/gstpad.c:4948 (discriminator 7)
#10 0x7f881a5e0c in gst_pad_pull_range r0/gst/gstpad.c:5193
#11 0x7f8816976c in gst_proxy_pad_getrange_default r0/gst/gstghostpad.c:185 (discriminator 2)
#12 0x7f88197214 in gst_pad_get_range_unchecked r0/gst/gstpad.c:4948 (discriminator 7)
#13 0x7f881a5e0c in gst_pad_pull_range r0/gst/gstpad.c:5193
#14 0x7f88197214 in gst_pad_get_range_unchecked r0/gst/gstpad.c:4948 (discriminator 7)
#15 0x7f881a5e0c in gst_pad_pull_range r0/gst/gstpad.c:5193
#16 0x7f85b1756c in gst_wavparse_stream_headers r0/gst/wavparse/gstwavparse.c:1555
#17 0x7f85b1a61c in gst_wavparse_loop r0/gst/wavparse/gstwavparse.c:2252 (discriminator 7)
#18 0x7f88201678 in gst_task_func r0/gst/gsttask.c:384
#19 0x7f885c1b44 in g_thread_pool_thread_proxy r0/glib/gthreadpool.c:352
#20 0x7f885c0eb4 in g_thread_proxy r0/glib/gthread.c:831
#21 0x7f87d7eea0 in start_thread r1/nptl/pthread_create.c:444
#22 0x7f87de59d8 in thread_start r1/misc/../sysdeps/unix/sysv/linux/aarch64/clone.S:79```This should be possible to get when running gst-launch-1.0 -v playbin uri=file://<file>. I have tried with using valgrind, address sanitizer or GST_TRACERS, all are showing the memory leak.
Running xxd <file> | less command on a file that is not leaking looks like:
00000000: 5249 4646 a488 0300 5741 5645 666d 7420 RIFF....WAVEfmt
00000010: 1000 0000 0100 0200 401f 0000 007d 0000 ........@....}..
00000020: 0400 1000 6461 7461 8088 0300 0000 0000 ....data........
00000030: 0000 0000 0000 0000 0000 0000 0000 0000 ................This makes sense for me when looking at the WAV file format
Now looking on a file that causes a leak:
00000000: 5249 4646 e001 0c00 5741 5645 4a55 4e4b RIFF....WAVEJUNK
00000010: 4000 0000 e001 0c00 0000 0000 e8fc 0b00 @...............
00000020: 0000 0000 7cff 0100 0000 0000 0000 0000 ....|...........
00000030: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000040: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000050: 0000 0000 666d 7420 1000 0000 0100 0200 ....fmt ........
00000060: 44ac 0000 9809 0400 0600 1800 6461 7461 D...........data
00000070: e8fc 0b00 0000 0000 0000 0000 0000 0000 ................Now there is "JUNK" after WAVE field. To my understanding this is not wrong.... according to Wikipedia.
Knowing all this I am very confused as in the "gst_wavparse_stream_headers" function the memory leak is made in a switch statement that I don't believe it should be in. In the first case statement it matches on GST_RIFF_TAG_LIST and inside it matches on the GST_RIFF_LIST_adtl, both I feel should not be a match as I don't see it in "xxd" commands output. Have not worked much with parsers so can be missing something, however I am grateful for any help and explanation that you can provide.