Bug 740505 – rtspsrc: segmentation fault when requesting srtp key

After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.

Bug 740505 - rtspsrc: segmentation fault when requesting srtp key


Summary:	rtspsrc: segmentation fault when requesting srtp key


Status:	RESOLVED FIXED

Product:	GStreamer
Classification:	Platform
Component:	gst-plugins-good
Version:	git master
Hardware:	Other Linux

Importance:	Normal critical
Target Milestone:	1.5.1
Assigned To:	GStreamer Maintainers
QA Contact:	GStreamer Maintainers

URL:
Whiteboard:

Depends on:
Blocks:

Reported:	2014-11-21 19:38 UTC by Aleix Conchillo Flaqué
Modified:	2014-12-31 13:23 UTC

See Also:
GNOME target:	---
GNOME version:	---

Attachments
set to PLAYING state after configuring the caps (1.51 KB, patch) 2014-11-21 19:42 UTC, Aleix Conchillo Flaqué	committed	Details \| Review

Description Aleix Conchillo Flaqué 2014-11-21 19:38:31 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.

+ Trace 234359

Thread 70 (Thread 0x7f1499a6d700 (LWP 16326))

#0 _IO_old_init
at genops.c line 617
#1 _IO_no_init
at genops.c line 649
#2 __GI___vasprintf_chk
at vasprintf_chk.c line 56
#3 g_vasprintf
from /opt/oblong/deps-64-10/lib/libglib-2.0.so.0
#4 g_strdup_vprintf
from /opt/oblong/deps-64-10/lib/libglib-2.0.so.0
#5 g_logv
from /opt/oblong/deps-64-10/lib/libglib-2.0.so.0
#6 g_log
from /opt/oblong/deps-64-10/lib/libglib-2.0.so.0
#7 gst_caps_set_simple
at gstcaps.c line 1049
#8 gst_rtspsrc_configure_caps
at gstrtspsrc.c line 4041
#9 gst_rtspsrc_play
at gstrtspsrc.c line 7450
#10 gst_rtspsrc_thread
at gstrtspsrc.c line 7739
#11 gst_task_func
at gsttask.c line 317
#12 ??
from /opt/oblong/deps-64-10/lib/libglib-2.0.so.0
#13 ??
from /opt/oblong/deps-64-10/lib/libglib-2.0.so.0
#14 start_thread
at pthread_create.c line 308
#15 clone
at ../sysdeps/unix/sysv/linux/x86_64/clone.S line 112
#16 ??

Comment 1 Aleix Conchillo Flaqué 2014-11-21 19:42:42 UTC

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.

Comment 2 Aleix Conchillo Flaqué 2014-11-21 19:47:17 UTC

(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...

Comment 3 Aleix Conchillo Flaqué 2014-11-22 16:03:39 UTC

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.

Wim?

Comment 4 Aleix Conchillo Flaqué 2014-12-12 06:52:29 UTC

Any comments on this one?

Comment 5 Tim-Philipp Müller 2014-12-31 13:23:20 UTC

Thanks, pushed:

 commit 07c5d1820abc99a6f330091acd84f58042908860
 Author: Aleix Conchillo Flaqué <aleix@oblong.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.
    
    https://bugzilla.gnome.org/show_bug.cgi?id=740505