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 692433 - segmentation fault when client disconnects
segmentation fault when client disconnects
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-rtsp-server
0.10.x
Other Linux
: Normal critical
: 1.2.3
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2013-01-24 09:09 UTC by Andrzej Bieniek
Modified: 2014-02-25 22:29 UTC
See Also:
GNOME target: ---
GNOME version: ---

Attachments
sleep(5) addition to trigger the failure. (2.72 KB, patch)
2013-01-24 09:09 UTC, Andrzej Bieniek 		none Details | Review
crashlog with callstacks (12.88 KB, text/plain)
2013-01-24 09:13 UTC, Andrzej Bieniek 		  Details

Description Andrzej Bieniek 2013-01-24 09:09:49 UTC 
Created attachment 234287 [details] [review]
sleep(5) addition to trigger the failure.

segmentation fault when client disconnects

When TCP client disconnects sometimes rtsp server crashes with segmentation fault. With more clients disconnecting it is more likely to see the crash. Streaming thread in do_send_data writes to client->watch which was already freed when client disconnected. 
I think it also applies to RTP/UDP clients but is much less likely to happen.

I've added sleep(5) statement and couple of printfs to reproduce the failure every time on PC. Additionally I find out that tr->send_rtp can be NULL in handle_new_buffer function.
To reproduce I apply attached patch and run gst-launch client with (protocols=4 for TCP), then kill appropriate client with CTRL+C.
Client needs to be killed when additional debug prints "kill client 0x8227428 now .." :)

I'm not sure what is a best way to fix it?

Two crash cases:
--- 1 single client disconnection ---
kill client 0x8227428 now ..    sending data to watch 0x8227428->0x8227c00 (0)..done
kill client 0x8227428 now ..    sending data to watch 0x8227428->0x8227c00 (0)..done
kill client 0x8227428 now ..    sending data to watch 0x8227428->0x8227c00 (0)..
Program received signal SIGSEGV, Segmentation fault.

+ Trace 231427

Thread 3044014912 (LWP 25209)

  • #0 handle_new_buffer
    at rtsp-media.c line 1244
  • #1 gst_app_sink_render_common
    at gstappsink.c line 793
  • #2 gst_base_sink_render_object 






Comment 1


Andrzej Bieniek





          2013-01-24 09:13:29 UTC
        



Created attachment 234288 [details]
crashlog with callstacks

Attaching full crashlog with callstacks for two cases.






Comment 2


Wim Taymans





          2013-01-28 10:40:32 UTC
        



with this patch I can't seem to get the error anymore in 1.0:

commit 6db0dbc76cf215eac8e4771e9672a268fb840bb9
Author: Wim Taymans <wim.taymans@collabora.co.uk>
Date:   Mon Jan 28 10:31:50 2013 +0100

    client: make sure the watch exists while sending data
    
    Protect the send_func with a lock. This allows us to wait for sending
    to complete before changing the send_func and user_data. We add an
    extra ref to the watch to make sure that it remains valid during
    sending.
    When closing the connection, set the send_func to NULL
    
    Fixes https://bugzilla.gnome.org/show_bug.cgi?id=692433