matroskademux: race when src pads are created
A race condition exists in matroska-demux.c
When it occurs: The application thread, AT is changing state from PAUSED->READY. The Streaming thread, ST is in the process of setting up a src pad eg Audio. ST is in the process of creating the src PAD and concurrently AT is closing down the same src PAD.
I our specific case the problem was seen when the signal "pad-added" was calling a callback (in ST). That callback will do linking. But when it tried to get the src PAD caps by gst_pad_get_current_caps there were no caps. They had been removed precisely before by AT.
AT was doing: gst_element_change_state_func -> gst_element_pads_activate (element, FALSE) ->gst_pad_set_active->>activate_mode_internal> post_activate->remove_events (pad)
ST was doing: gst_matroska_demux_add_stream -> "pad-added" signal CB
One possible solution is to add a gst_pad_set_activatemode_function to each src PAD created. In that function one calls gst_pad_stop_task (src PAD) that will stop the ST and join it with AT. At least one downside with this proposed solution is that the gst_pad_stop_task will be called several times once from sink and some from the src PADs (now only sink PAD has a gst_pad_set_activatemode_function that closes down the ST by calling gst_pad_stop_task). Also the Streamin thread probably belongs to sink PAD not to src PAD/PADs.