CameraHal: Fixes a possible race cond. and subsequent freeze

- The notification thread in 'AppCallbackNotifier' will
  check for pending messages in 'mEventQ' and call
  'notifyEvent()' when data is available. On the other
  hand 'notifyEvent()' will lock 'mLock' and read the
  incoming events from 'mEventQ'. It is possible for the
  client to call 'cancelAutoFocus()' between the check
  for messages in the notification thread and the lock
  in 'notifyEvent()' effectively flushing all messages
  in 'mEventQ'. In this case 'notifyEvent()' will try
  to read the incoming data block and with it also block
  'mLock'. This sequence will cause the camera client
  to freeze in the following calls as well. Solution is
  to check 'mEventQ' for pending messages inside
  'notifyEvent()' after 'mLock' is acquired and before
  trying to retrieve any data.

Change-Id: I92b5e8e3c2be9bd4985d2ae511eedc7eed957241
Signed-off-by: Emilian Peev <epeev@mm-sol.com>

1 files changed, 6 insertions, 2 deletions

diff --git a/camera/AppCallbackNotifier.cpp b/camera/AppCallbackNotifier.cpp
index 629dee5..6550d1c 100644
--- a/camera/AppCallbackNotifier.cpp
+++ b/camera/AppCallbackNotifier.cpp
@@ -314,8 +314,12 @@ void AppCallbackNotifier::notifyEvent()
     TIUTILS::Message msg;
     LOG_FUNCTION_NAME;
     {
-    Mutex::Autolock lock(mLock);
-    mEventQ.get(&msg);
+        Mutex::Autolock lock(mLock);
+        if ( !mEventQ.hasMsg() ) {
+            return;
+        } else {
+            mEventQ.get(&msg);
+        }
     }
     bool ret = true;
     CameraHalEvent *evt = NULL;