Random crashes when stopping playback of multiple videos
Describe your issue
I'm updating an app that plays a number of playbin3
elements at once (they are all children of a single GstPipeline
). When the app is closed it sets the pipeline state to NULL
.
I've been hitting random segfaults from GStreamer threads when closing the app. It's easiest to reproduce when running under a debugger, opening five or so video files, then closing the app before they all finished prerolling.
Generally the segfaults look something like this, with the "corrupted size vs. prev_size in fastbins" message:
I tried reproducing the crash under valgrind a few times and got these messages in the log:
==168892== Thread 60 multiqueue2:src_:
==168892== Invalid read of size 8
==168892== at 0x446E91F8: si_switch_compute_shader (si_compute.c:530)
==168892== by 0x446E91F8: si_launch_grid (si_compute.c:963)
==168892== by 0x446EA90A: si_launch_grid_internal (si_compute_blit.c:94)
==168892== by 0x446EC701: si_compute_clear_render_target (si_compute_blit.c:856)
==168892== by 0x4449B740: vlVaHandleSurfaceAllocate (surface.c:812)
==168892== by 0x4449C1E3: vlVaCreateSurfaces2.part.0 (surface.c:1003)
==168892== by 0x3DDEBE97: vaCreateSurfaces (va.c:1182)
==168892== by 0x3DD6BA70: UnknownInlinedFun (gstvaapisurface.c:220)
==168892== by 0x3DD6BA70: gst_vaapi_surface_new_full (gstvaapisurface.c:431)
==168892== by 0x3DD99996: UnknownInlinedFun (gstvaapisurface.c:466)
==168892== by 0x3DD99996: context_ensure_surfaces (gstvaapicontext.c:200)
==168892== by 0x3DD99F24: context_create (gstvaapicontext.c:258)
==168892== by 0x3DD9BA7B: UnknownInlinedFun (gstvaapicontext.c:526)
==168892== by 0x3DD9BA7B: gst_vaapi_context_new (gstvaapicontext.c:490)
==168892== by 0x3DD4C3FB: gst_vaapi_decoder_ensure_context (gstvaapidecoder.c:981)
==168892== by 0x3DD51869: UnknownInlinedFun (gstvaapidecoder_h264.c:1655)
==168892== by 0x3DD51869: UnknownInlinedFun (gstvaapidecoder_h264.c:4170)
==168892== by 0x3DD51869: gst_vaapi_decoder_h264_start_frame.lto_priv.0 (gstvaapidecoder_h264.c:4875)
==168892== Address 0xa8 is not stack'd, malloc'd or (recently) free'd
==168892==
==168892==
==168892== Process terminating with default action of signal 11 (SIGSEGV): dumping core
==168892== Access not within mapped region at address 0xA8
==168892== at 0x446E91F8: si_switch_compute_shader (si_compute.c:530)
==168892== by 0x446E91F8: si_launch_grid (si_compute.c:963)
==168892== by 0x446EA90A: si_launch_grid_internal (si_compute_blit.c:94)
==168892== by 0x446EC701: si_compute_clear_render_target (si_compute_blit.c:856)
==168892== by 0x4449B740: vlVaHandleSurfaceAllocate (surface.c:812)
==168892== by 0x4449C1E3: vlVaCreateSurfaces2.part.0 (surface.c:1003)
==168892== by 0x3DDEBE97: vaCreateSurfaces (va.c:1182)
==168892== by 0x3DD6BA70: UnknownInlinedFun (gstvaapisurface.c:220)
==168892== by 0x3DD6BA70: gst_vaapi_surface_new_full (gstvaapisurface.c:431)
==168892== by 0x3DD99996: UnknownInlinedFun (gstvaapisurface.c:466)
==168892== by 0x3DD99996: context_ensure_surfaces (gstvaapicontext.c:200)
==168892== by 0x3DD99F24: context_create (gstvaapicontext.c:258)
==168892== by 0x3DD9BA7B: UnknownInlinedFun (gstvaapicontext.c:526)
==168892== by 0x3DD9BA7B: gst_vaapi_context_new (gstvaapicontext.c:490)
==168892== by 0x3DD4C3FB: gst_vaapi_decoder_ensure_context (gstvaapidecoder.c:981)
==168892== by 0x3DD51869: UnknownInlinedFun (gstvaapidecoder_h264.c:1655)
==168892== by 0x3DD51869: UnknownInlinedFun (gstvaapidecoder_h264.c:4170)
==168892== by 0x3DD51869: gst_vaapi_decoder_h264_start_frame.lto_priv.0 (gstvaapidecoder_h264.c:4875)
==168892== If you believe this happened as a result of a stack
==168892== overflow in your program's main thread (unlikely but
==168892== possible), you can try to increase the size of the
==168892== main thread stack using the --main-stacksize= flag.
==168892== The main thread stack size used in this run was 8388608.
Setup
- Operating System: Fedora 36 Silverblue, running the app in a Fedora 35 toolbox
- Device: Computer
- GStreamer Version: gstreamer1-1.20.0-1.fc35.x86_64, gstreamer1-vaapi-1.20.0-1.fc35.x86_64
How reproducible is the bug?
Pretty frequently on my setup; the more videos the more likely it happens, but running without a debugger decreases the likelihood.