Fixed a possible hanging bug in the Symbian networking.

I haven't seen the bug happening in practice, but I decided to be
safe rather than sorry.

The rationale is that if a network request comes in, the select
thread will signal the active object in the main thread, remove the
socket from the set of monitored sockets, and then go to sleep in the
waitCond.wait() call, waiting for reactivation by the
QSelectMutexGrabber. However, in
QEventDispatcherSymbian::socketFired(), if the event causes the
socket to be deleted, reactivateSocketNotifier will never be called,
and therefore the wait condition will never be terminated.

Fixed by only entering the wait condition if a grabber has already
written to the pipe, signalling that it wants the lock.

AutoTest: Passed
RevBy:    Markus Goetz
(cherry picked from commit fc260f7ce9c139da93e005b2b51ef37c4d23998d)

1 files changed, 2 insertions, 1 deletions

diff --git a/src/corelib/kernel/qeventdispatcher_symbian.cpp b/src/corelib/kernel/qeventdispatcher_symbian.cpp
index e86efb2..2717780 100644
--- a/src/corelib/kernel/qeventdispatcher_symbian.cpp
+++ b/src/corelib/kernel/qeventdispatcher_symbian.cpp
@@ -481,7 +481,8 @@ void QSelectThread::run()
             updateActivatedNotifiers(QSocketNotifier::Write, &writefds);
         }
 
-        m_waitCond.wait(&m_mutex);
+        if (FD_ISSET(m_pipeEnds[0], &readfds))
+            m_waitCond.wait(&m_mutex);
     }
 
     m_mutex.unlock();