[gstreamer-bugs] [Bug 567857] New: [udpsrc] loop on gst_poll_wait when POLLERR because of icmp

[GStreamer (bugzilla.gnome.org)]

If you have any questions why you received this email, please see the text at
the end of this email. Replies to this email are NOT read, please see the text
at the end of this email. You can add comments to this bug at:
  http://bugzilla.gnome.org/show_bug.cgi?id=567857

  GStreamer | gst-plugins-good | Ver: HEAD CVS
           Summary: [udpsrc] loop on gst_poll_wait when POLLERR because of
                    icmp
           Product: GStreamer
           Version: HEAD CVS
          Platform: Other
        OS/Version: Linux
            Status: UNCONFIRMED
          Severity: normal
          Priority: Normal
         Component: gst-plugins-good
        AssignedTo: gstreamer-bugs at lists.sourceforge.net
        ReportedBy: gstelzz at yahoo.fr
         QAContact: gstreamer-bugs at lists.sourceforge.net
     GNOME version: Unspecified
   GNOME milestone: Unspecified


I am using the same fd to send and recv rtp.
This fd is used in gstudpsink and gstudpsrc.
udpsrc tries to read from fd while udpsink sends RTP.

When distant is unreachable, udpsink sendto will lead to a icmp packet sent
back.
Therefore, ppoll in gst_poll_wait called from udpsrc will return 1 with POLLERR
set on rtp fd.
udpsrc then loops on poll because FIONREAD returns 0 (icmp packet).
When next RTP packet is sent (20ms later in ALAW there), sendto returns an
error and the udpsink post a message on bus : Connection refused.
Meanwhile (20ms) udpsrc looped about a hundred times on poll, consuming all
cpu.

The comment before retry in gstudpsrc.c is right : "We know someone will also
do something with the socket so that we don't go into an infinite loop in the
select()"
Problem is when ?

We can choose to stop the udpsrc when the message 'Connection refused' is
received on bus. This means that all cpu will be consumed for 20 ms.

Moreover, the icmp error may only be temporary. It may happen at the beginning
of the process, just let the distant time to bind its ports (It should have
done it before, right, but who knows ? : linphone for instance has such bug)

So the problem is about icmp errors on RTP sockets.
Are they considered to be fatal (therefore, why loop on udpsrc ?) or not and we
have a performance issue.

fd has POLLERR revent anytime the poll is done, this is why loop is so fast.
But pollerr is set only when icmp is received because of a send.

POLLERR should be flushed before loop on poll.
This can be done using recvmsg : patch attached.

side effect : udpsink does not see error anymore and does not return
GST_FLOW_ERROR


-- 
See http://bugzilla.gnome.org/page.cgi?id=email.html for more info about why you received
this email, why you can't respond via email, how to stop receiving
emails (or reduce the number you receive), and how to contact someone
if you are having problems with the system.

You can add comments to this bug at http://bugzilla.gnome.org/show_bug.cgi?id=567857.