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 727488 - There is a race when disconnecting POST channel in tunneled mode
There is a race when disconnecting POST channel in tunneled mode
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-rtsp-server
git master
Other Linux
: Normal normal
: 1.3.1
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2014-04-02 10:32 UTC by Ognyan Tonchev (redstar_)
Modified: 2014-04-08 14:28 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
client: remove watch of the second client after http tunnel setup (1.16 KB, patch)
2014-04-02 10:34 UTC, Ognyan Tonchev (redstar_)
committed Details | Review
client: support for POST before GET when setting up a tunnel (5.52 KB, patch)
2014-04-03 10:29 UTC, Ognyan Tonchev (redstar_)
committed Details | Review

Description Ognyan Tonchev (redstar_) 2014-04-02 10:32:50 UTC
Right now there is a race when disconnecting POST channel in tunneled mode and sometimes it is not possible to create new POST connection afterwards.

After tunnel setup the first client owns the POST and the GET connections and the second client will be freed. But before it is freed its RTSP Watch will get dispatched and call the closed() callback. From closed() the server tries to remove the tunnelid from the hash table with the pending tunnels. And that is a problem if the POST was already disconnected and the tunnel marked as pending.

I think that the client which got the POST connection should never touch the hash table with the pending tunnels. It is a responsibility of the client owning the tunnel to do that.
Comment 1 Ognyan Tonchev (redstar_) 2014-04-02 10:34:20 UTC
Created attachment 273462 [details] [review]
client: remove watch of the second client after http tunnel setup

This is just one way to solve the problem, not sure if that's the perfect way though.
Comment 2 Ognyan Tonchev (redstar_) 2014-04-03 10:29:30 UTC
Created attachment 273516 [details] [review]
client: support for POST before GET when setting up a tunnel

I am attaching this new patch to this same bugzilla ticket since it is kind of related to the above fix.
Comment 3 Wim Taymans 2014-04-08 14:18:01 UTC
commit 132f77751d72b9942de25aee4071ba27b9829d28
Author: Ognyan Tonchev <ognyan@axis.com>
Date:   Wed Apr 2 12:03:32 2014 +0200

    client: remove watch of the second client after http tunnel setup
    
    The second client will be freed after the HTTP tunnel has been set up.
    Make sure it's RTSP watch is never dispatched again.
    
    Fixes https://bugzilla.gnome.org/show_bug.cgi?id=727488
Comment 4 Wim Taymans 2014-04-08 14:28:30 UTC
commit 0493a63a652bec39b2db56c2c0c4c4779091c6f5
Author: Ognyan Tonchev <ognyan@axis.com>
Date:   Thu Apr 3 12:19:51 2014 +0200

    client: support for POST before GET when setting up a tunnel