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

Stale socket notifications can be emitted to new sockets



    • Type: Bug
    • Status: Closed
    • Priority: P2: Important
    • Resolution: Done
    • Affects Version/s: 5.15, 6.0
    • Fix Version/s: 6.1.3, 6.3.0 Alpha
    • Component/s: Network: Sockets
    • Labels:
    • Platform/s:
    • Commits:
      fe6d84d96e67113846801803c3ba1f20b26e123f (qt/qtbase/dev) 1489567b3b80578cb2c4daf33ad774429afeaf4f (qt/qtbase/6.1)


      Following QTBUG-82776 it is shown that, sometimes, notifications meant for sockets that are now closed are still left in the queue. This is documented[0] and usually it is not a problem since we will discard the events the next time the event-loop is spun. When the event-loop is not spun Windows could reuse the old socket descriptor for a newly created socket (in the related bug-report I could usually reproduce locally after 10-20 runs).

      So, steps:

      1. Create socket
      2. Use socket
      3. Close socket (generates a close notification)
      4. Create new socket (and it ends up assigned with the socket descriptor from the first socket)
      5. Spin the event loop to deliver the stale socket notification
      6. The new socket handles it, some side-effects depending on the notification
        1. e.g. a close notification will try to read data, if no data is available it will disconnect

      A possible way this could be fixed would be to somehow remove the related notifications once the socketnotifier is unregistered, but it's not that easy. PeekMessage only shows the first message of a certain type, that means if there are multiple socketnotifiers then if the first message is not related to the current socketnotifier being unregistered then there's no way to access the rest. Removing and requeuing all of them is likely not an option.

      [0] https://docs.microsoft.com/en-us/windows/win32/api/winsock/nf-winsock-wsaasyncselect#remarks 


      Although WSAAsyncSelect immediately disables event message posting for the socket in this instance, it is possible that messages could be waiting in the application message queue. Therefore, the application must be prepared to receive network event messages even after cancellation. Closing a socket with closesocket also cancels WSAAsyncSelect message sending, but the same caveat about messages in the queue still applies.


          Issue Links

          For Gerrit Dashboard: QTBUG-82835
          # Subject Branch Project Status CR V



              cnn Qt Core & Network
              manordheim Mårten Nordheim
              0 Vote for this issue
              1 Start watching this issue