Uploaded image for project: 'Qt'
  1. Qt
  2. QTBUG-47860

QUdpSocket stops emitting readyRead signal

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Not Evaluated
    • Resolution: Duplicate
    • Affects Version/s: 5.4.0, 5.5.0
    • Fix Version/s: None
    • Component/s: Network: Sockets
    • Labels:
      None

      Description

      This change: https://codereview.qt-project.org/#/c/104120/
      has caused a problem when using QUdpSocket where it will stop emitting the readyRead signal after a while.

      We use the (faulty) QUdpSocket for reading only and we have different sending (UDP) streams.

      One version uses a file based input, which is highly regular and when we use this the behaviour is as expected: we get readyRead every time data arrives.
      The other version uses sampled data from a device, which gets processed etc, which causes the timing of packets wrt each other to vary much more. If we stream from this part (using the exact same protocols and objects), after a few received packets the QUdpSocket will stop emitting the readyRead signal.
      It just suddenly stops. The object still exists, its connections are still there, etc. If we check the buffers, we can see that there is actually data in the queue, just the signal is never emitted anymore.

      After much digging around, we reverted the mentioned change (which has caused a change in the behaviour of temporarily disabling this particular signal) and after we revert this, we get the expected behaviour for QUdpSocket again (ie. everything works and we keep getting the readyRead signal)

      I suspect that the new check socketEngine->hasPendingDatagrams() causes a race condition. Perhaps my function already stopped reading datagrams because there are no more, but it hasn't returned yet, then a new datagram arrives and then no readyRead is emitted, then my function returns and the signal could be enabled, but now there already is a datagram in the queue which disables the signal again.

      We've reverted the change locally, since we're not experiencing the problem that it was supposed to fix, but I expect that this should be fixed properly

        Attachments

          Issue Links

          No reviews matched the request. Check your Options in the drop-down menu of this sections header.

            Activity

              People

              Assignee:
              richmoore Richard Moore (qtnetwork)
              Reporter:
              wathiant Job Mulder
              Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved:

                  Gerrit Reviews

                  There are no open Gerrit changes