GNOME Bugzilla – Bug 740505
rtspsrc: segmentation fault when requesting srtp key
Last modified: 2014-12-31 13:23:53 UTC
If request_key signal callback is executed at the same time as gst_rtspsrc_configure_caps (which is called from gst_rtspsrc_play) we end up crashing.
My guess is that we start receiving packets while configuring the caps. Because packets are encrypted we request a key. request_key modifies the caps as well as gst_rtspsrc_configure_caps.
(xxxxx:33046): GStreamer-CRITICAL **: gst_caps_set_simple: assertion 'IS_WRITABLE (caps)' failed
Thread 70 below shows the assertion and the caps that fails is the same pointer that make Thread 1 to crash.
(Thread 0x7f1499a6d700 (LWP 16326))
Created attachment 291199 [details] [review]
set to PLAYING state after configuring the caps
I'm trying this patch. Basically, we set the PLAYING state after we have configured the caps.
(In reply to comment #1)
> Created an attachment (id=291199) [details] [review]
> set to PLAYING state after configuring the caps
> I'm trying this patch. Basically, we set the PLAYING state after we have
> configured the caps.
I'm not really sure if we can lose any initial packets with this patch...
It seems the patch is fine after 10 hours and ~36000 connections.
Also, I don't think we can lose any packet because udpsrc opens the socket on the READY state which I think rtspsrc does initially and the SO already has a buffer. So, I don't think it's very likely that we lose anything when we send the PLAY request and we are waiting for the response. May be I'm wrong though.
Any comments on this one?
Author: Aleix Conchillo Flaqué <email@example.com>
Date: Fri Nov 21 11:39:19 2014 -0800
rtspsrc: set PLAYING state after configuring caps
We set to PLAYING after we have configured the caps, otherwise we
might end up calling request_key (with SRTP) while caps are still
being configured, ending in a crash.