Camera1: JpegProcessor: Do not lock until we have to
JpegProcessor::onBufferReleased is fired for both successful and failed
Jpeg captures, but only cares about the failures.
In success cases, onBufferReleased is always fired some time after
onFrameAvailable, and sometimes the thread scheduling pushes
onBufferReleased to be so late that preview restart has started, which
can cause a deadlock with onBufferReleased acquiring locks in the
opposite order that preview startup will.
To fix, move the JpegProcessor mutex acquire to only happen in the error
cases, in which case onFrameAVailable will not have fired, and the
camera state will still be STILL_CAPTURE, not STOPPED or mid-preview
startup.
Bug: 29524651
Change-Id: I3f103e070c3b39c38117b91824cd79c5dfc757ac
diff --git a/services/camera/libcameraservice/api1/client2/JpegProcessor.cpp b/services/camera/libcameraservice/api1/client2/JpegProcessor.cpp
index ffe96fc..d6d8dde 100644
--- a/services/camera/libcameraservice/api1/client2/JpegProcessor.cpp
+++ b/services/camera/libcameraservice/api1/client2/JpegProcessor.cpp
@@ -67,10 +67,15 @@
}
void JpegProcessor::onBufferReleased(const BufferInfo& bufferInfo) {
- Mutex::Autolock l(mInputMutex);
ALOGV("%s", __FUNCTION__);
-
if (bufferInfo.mError) {
+ // Only lock in case of error, since we get one of these for each
+ // onFrameAvailable as well, and scheduling may delay this call late
+ // enough to run into later preview restart operations, for non-error
+ // cases.
+ // b/29524651
+ ALOGV("%s: JPEG buffer lost", __FUNCTION__);
+ Mutex::Autolock l(mInputMutex);
mCaptureDone = true;
mCaptureSuccess = false;
mCaptureDoneSignal.signal();
