Android的BUG（二） – SurfaceTexture中的野指標

當初遇到這個bug，是不週期性低機率出現，最後找到一個比較容易重現的步驟：

啟動系統
然後進google +
 建立一個帳號(注意是建立一個帳號)
 沒幾步就重啟了 

這個BUG，一開始追蹤也是無頭緒的，在這個bug出現時，系統的debuggerd還是有些問題，pt_regs設定的和核心對應不上，tombstone的資訊完全無用，core dump功能也是無法使用，唯一的線索就是一點點logcat的trace， trace如下：

D/OpenGLRenderer( 2021): Flushing caches (mode 1)D/OpenGLRenderer( 2021): Flushing caches (mode 0)D/OpenGLRenderer( 1986): Flushing caches (mode 1)W/SurfaceTexture( 1451): freeAllBuffersLocked called but mQueue is not emptyD/OpenGLRenderer( 1986): Flushing caches (mode 0)F/libc    ( 1451): Fatal signal 11 (SIGSEGV) at 0x00000024 (code=1)I/DEBUG   ( 1449): *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***I/DEBUG   ( 1449): Build fingerprint: 'xxxx/IML74K/eng.freshui.20120213.154128:user/test-keys'I/DEBUG   ( 1449): pid: 1451, tid: 1455  >>> /system/bin/surfaceflinger <<<I/DEBUG   ( 1449): signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 00000024

重現時的錯誤，基本上都是類似的trace。 從此入手開始尋找。 Trace中的一句話：

W/SurfaceTexture( 1451): freeAllBuffersLocked called but mQueue is not empty

是最大的懷疑目標，基於捉蟲的經驗，先做假定，已經可以解釋出錯的原因和現象了：

•  mQueue通常是被兩個模組使用的，一個enqueue，一個dequeue
• 出錯時，要將mQueue 給free掉，但mQueue不空，說明有人在用
• 如果不管這個警告，強行將mQueue給free掉，極有可能造成另外一個模組使用被free掉的記憶體而引起段錯誤

轉回頭看代碼,SurfaceTexture.cpp， 查一下mQueue的使用地方，哪裡有出現free buffer的時候，mQueue 不為空白的可能？ 排查一下，還真找到了，看下這個函數：

 

status_t SurfaceTexture::setBufferCount(int bufferCount) {    ST_LOGV("setBufferCount: count=%d", bufferCount);    Mutex::Autolock lock(mMutex);    if (mAbandoned) {        ST_LOGE("setBufferCount: SurfaceTexture has been abandoned!");        return NO_INIT;    }    if (bufferCount > NUM_BUFFER_SLOTS) {        ST_LOGE("setBufferCount: bufferCount larger than slots available");        return BAD_VALUE;    }    // Error out if the user has dequeued buffers    for (int i=0 ; i<mBufferCount ; i++) {        if (mSlots[i].mBufferState == BufferSlot::DEQUEUED) {            ST_LOGE("setBufferCount: client owns some buffers");            return -EINVAL;        }    }    const int minBufferSlots = mSynchronousMode ?            MIN_SYNC_BUFFER_SLOTS : MIN_ASYNC_BUFFER_SLOTS;    if (bufferCount == 0) {        mClientBufferCount = 0;        bufferCount = (mServerBufferCount >= minBufferSlots) ?                mServerBufferCount : minBufferSlots;        return setBufferCountServerLocked(bufferCount);    }    if (bufferCount < minBufferSlots) {        ST_LOGE("setBufferCount: requested buffer count (%d) is less than "                "minimum (%d)", bufferCount, minBufferSlots);        return BAD_VALUE;    }    // here we're guaranteed that the client doesn't have dequeued buffers    // and will release all of its buffer references.    freeAllBuffersLocked();    mBufferCount = bufferCount;    mClientBufferCount = bufferCount;    mCurrentTexture = INVALID_BUFFER_SLOT;    mQueue.clear();    mDequeueCondition.signal();    return OK;}

找到問題後，在freeAllBuffersLocked()調用之前，將mQueue給抽幹一下，等使用的client都用完了再free就好了。

修改之後，再也沒有碰到此類錯誤了。

當然此問題的排查和解決過程沒這麼順利，也是搞了好幾天的。 解決方案和問題原因也就不細說了，碰到並準備捉這個蟲的同學應該會看明白的。

呵呵，這又是可以歸結為 多線程同步/狀態機器 的問題，基本上目前我在Android碰到的嚴重問題都是這類了