GNOME Bugzilla – Bug 790007
decodebin2: Wait for cleanup thread to finish
Last modified: 2017-11-10 16:24:44 UTC
This is a race, but sometimes we end up trying to use a mutex which was already freed. Running command: /mnt/scratch0/clusterfuzz/slave-bot/builds/clusterfuzz-builds_gstreamer_679d89211639450175bee2d209c1aefe68250fd9/revisions/gst-discoverer -timeout=25 -rss_limit_mb=2048 -runs=100 /bb5f62e3925e1dd946f79d0faa3a47128fuzz-1-gstreamer_gst-discoverer INFO: Seed: 2327548772 INFO: Loaded 1 modules (75961 guards): 75961 [0x13dee68, 0x142914c), /mnt/scratch0/clusterfuzz/slave-bot/builds/clusterfuzz-builds_gstreamer_679d89211639450175bee2d209c1aefe68250fd9/revisions/gst-discoverer: Running 1 inputs 100 time(s) each. Running: /bb5f62e3925e1dd946f79d0faa3a47128fuzz-1-gstreamer_gst-discoverer GLib (gthread-posix.c): Unexpected error from C library during 'pthread_mutex_lock': Invalid argument. Aborting. AddressSanitizer:DEADLYSIGNAL ================================================================= ==1==ERROR: AddressSanitizer: ABRT on unknown address 0x000000000001 (pc 0x7f58a29c0428 bp 0x7f589d076d70 sp 0x7f589d076c28 T10) SCARINESS: 10 (signal) #0 0x7f58a29c0427 in gsignal /build/glibc-9tT8Do/glibc-2.23/sysdeps/unix/sysv/linux/raise.c:54 #1 0x7f58a29c2029 in abort /build/glibc-9tT8Do/glibc-2.23/stdlib/abort.c:89 #2 0xadb7e0 in g_thread_abort /work/glib-2.54.2/glib/gthread-posix.c:78:3 #3 0xadb6c3 in g_mutex_lock /work/glib-2.54.2/glib/gthread-posix.c:215:5 #4 0x5fdedf in gst_decode_chain_free_internal /src/gst-plugins-base/gst/playback/gstdecodebin2.c:3400:5 #5 0x5fe659 in gst_decode_group_free_internal /src/gst-plugins-base/gst/playback/gstdecodebin2.c:3560:5 #6 0x60af61 in gst_decode_chain_free_hidden_groups /src/gst-plugins-base/gst/playback/gstdecodebin2.c:3656:5 #7 0xa9b187 in g_thread_proxy /work/glib-2.54.2/glib/gthread.c:784:20 #8 0x7f58a2f716b9 in start_thread #9 0x7f58a2a9182c in clone /build/glibc-9tT8Do/glibc-2.23/sysdeps/unix/sysv/linux/x86_64/clone.S:109 That thread is started by gst_decode_chain_start_free_hidden_groups_thread()
Updated title accordingly. The same issue is present in gstparsebin. We essentially need to join the thread when cleaning up (READY=>NULL)
*** Bug 790169 has been marked as a duplicate of this bug. ***
Created attachment 363345 [details] [review] decodebin2: Don't let thread run after unref We have a dedicated one-shot thread to handle cleanup of old groups. While this is a good idea. It's an even better idea to make sure that thread is *completed* before the decodebin2 element to which it is related isn't freed/gone. * There can only be one cleanup thread happening at any point in time. If there is already one, we wait for the previous one to finish. * When shutting down (NULL=>READY) make sure the thread is finished https://bugzilla.gnome.org/show_bug.cgi?id=790169
Created attachment 363355 [details] [review] parsebin: Don't let thread run after unref We have a dedicated one-shot thread to handle cleanup of old groups. While this is a good idea. It's an even better idea to make sure that thread is *completed* before the parsebin element to which it is related isn't freed/gone. * There can only be one cleanup thread happening at any point in time. If there is already one, we wait for the previous one to finish. * When shutting down (NULL=>READY) make sure the thread is finished
commit 35a8d42724d5f9753fc18a7d27a7bf16993eed78 Author: Edward Hervey <edward@centricular.com> Date: Fri Nov 10 14:54:12 2017 +0100 parsebin: Don't let thread run after unref We have a dedicated one-shot thread to handle cleanup of old groups. While this is a good idea. It's an even better idea to make sure that thread is *completed* before the parsebin element to which it is related isn't freed/gone. * There can only be one cleanup thread happening at any point in time. If there is already one, we wait for the previous one to finish. * When shutting down (NULL=>READY) make sure the thread is finished https://bugzilla.gnome.org/show_bug.cgi?id=790007 commit 43b9bcbddb6599fe05c1fafa3105412fedd07d23 Author: Edward Hervey <edward@centricular.com> Date: Fri Nov 10 14:54:12 2017 +0100 decodebin2: Don't let thread run after unref We have a dedicated one-shot thread to handle cleanup of old groups. While this is a good idea. It's an even better idea to make sure that thread is *completed* before the decodebin2 element to which it is related isn't freed/gone. * There can only be one cleanup thread happening at any point in time. If there is already one, we wait for the previous one to finish. * When shutting down (NULL=>READY) make sure the thread is finished https://bugzilla.gnome.org/show_bug.cgi?id=790007