Donate to e Foundation | Murena handsets with /e/OS | Own a part of Murena! Learn more

Commit d17c7da6 authored by Adithya Srinivasan's avatar Adithya Srinivasan
Browse files

Fix a memory leak with pending jank classifications

If the front of the pendingJankClassification deque is
stuck(FrameTimeline never received it) for some reason, the current
logic never releases it and the deque keeps growing in size until the
layer itself is destroyed. This has resulted in some memory leaks
recently.

Bug: 181328447
Test: heap_prof trace
Change-Id: If71225f52da3bbd9b0b0d46af75f933fd48d5bd5
parent 8503741e
Loading
Loading
Loading
Loading
+8 −0
Original line number Diff line number Diff line
@@ -171,6 +171,14 @@ void BufferStateLayer::onLayerDisplayed(const sp<Fence>& releaseFence) {

void BufferStateLayer::onSurfaceFrameCreated(
        const std::shared_ptr<frametimeline::SurfaceFrame>& surfaceFrame) {
    while (mPendingJankClassifications.size() >= kPendingClassificationMaxSurfaceFrames) {
        // Too many SurfaceFrames pending classification. The front of the deque is probably not
        // tracked by FrameTimeline and will never be presented. This will only result in a memory
        // leak.
        ALOGW("Removing the front of pending jank deque from layer - %s to prevent memory leak",
              mName.c_str());
        mPendingJankClassifications.pop_front();
    }
    mPendingJankClassifications.emplace_back(surfaceFrame);
}

+2 −0
Original line number Diff line number Diff line
@@ -173,6 +173,8 @@ private:
    nsecs_t mCallbackHandleAcquireTime = -1;

    std::deque<std::shared_ptr<android::frametimeline::SurfaceFrame>> mPendingJankClassifications;
    // An upper bound on the number of SurfaceFrames in the pending classifications deque.
    static constexpr int kPendingClassificationMaxSurfaceFrames = 25;

    const std::string mBlastTransactionName{"BufferTX - " + mName};
    // This integer is incremented everytime a buffer arrives at the server for this layer,