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
rtspsrc: segmentation fault when requesting srtp key
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-good
git master
Other Linux
: Normal critical
: 1.5.1
Assigned To: GStreamer Maintainers
GStreamer Maintainers
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.

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