[Bug 764744] Crashes when multiple udpsrc are created for each client on a shared media, misses tracking and cleanup

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=764744

--- Comment #16 from Sebastian Dröge (slomo) <slomo at coaxion.net> ---
(In reply to Jake Foytik from comment #15)
>  -- I've assumed that there can exist multiple unicast udpsrcs but only a
> single set of multicast udpsrcs (one for IPV4 and one for IPV6).
>    - The multicast udpsrcs remain the same.

Correct

>    - The unicast udpsrcs are now maintained in a hash table that uses the
> RTSPTransport as a key. It didn't look like there was any special logic
> required for handling IPV4 v. IPV6 except for the creation of the sockets,
> so the hash table can contain both types.

No special handling, correct

>    - When unicast sockets are allocated, the udpsrcs are stored in the hash
> table. See the gst_rtsp_stream_allocate_udp_sockets() function.
>    - When a client disconnects and the connection is unicast, we now cleanup
> the udpsrcs related to the RTSPTransport.  See update_transport() function.
>    - In the gst_rtsp_stream_leave_bin() function, all udpsrcs are now
> cleaned up.

Makes sense

>  -- I've made some fundamental changes to the
> gst_rtsp_stream_allocate_udp_sockets() function that I think are correct,
> but you should verify. They include:
>     - IPV6 unicast sockets were only allowed to be allocated one time, in
> the same manner as multicast. This is different for IPV4 unicast. I assumed
> that we wanted to allow multiple IPV6 unicast connections, so I removed the
> 'have_ipv6' check that would skip allocation.

Makes sense and is probably just an overlook. IPv4/6 should behave exactly the
same.

>     - I changed the logic for calculating the return 'result'. Before, it
> performed 'result = have_ipv4 || have_ipv4_mcast || have_ipv6 ||
> have_ipv6_mcast'. This would return TRUE if a client was trying to create an
> IPV4 unicast connection and it failed to allocate the unicast udpsrcs, but a
> client had previously connected with IPV6 multicast successfully.

That part looked weird to me last time I looked too, so that fix is probably
fine :)

> Please review the patch and make recommendations. I'll make changes as
> needed.

A unit test would be nice to have

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.