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

1 files changed, 2 insertions, 1 deletions

diff --git a/src/corelib/kernel/qeventdispatcher_symbian.cpp b/src/corelib/kernel/qeventdispatcher_symbian.cpp
index 7da1b69..1b0c31b 100644
--- a/src/corelib/kernel/qeventdispatcher_symbian.cpp
+++ b/src/corelib/kernel/qeventdispatcher_symbian.cpp
@@ -480,7 +480,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();