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

Commit 37dfb429 authored by John Reck's avatar John Reck
Browse files

Fix concurrent modification crash in onAlarm 

Change-Id: Idfd094f3c9ea59356440d6851ccd5abda36ca6ba
Fixes: 35640585
Test: manual; after boot, opened the power menu to force
system_server to spin up a ThreadedRenderer instance
(and thus register itself as a callback on GraphicsStatsService).
Then manually set the date forward by a day to trigger onAlarm
and verified the system didn't reboot/crash. A systrace capture
verified that the alarm fired and package:android (system_server)
had a log rotation event.
parent f9bd2944

services/core/java/com/android/server/GraphicsStatsService.java

+12 −7
Original line number Diff line number Diff line
@@ -137,10 +137,16 @@ public class GraphicsStatsService extends IGraphicsStats.Stub { 
    }



    private void onAlarm() {

        // We need to make a copy since some of the callbacks won't be proxy and thus

        // can result in a re-entrant acquisition of mLock that would result in a modification

        // of mActive during iteration.

        ActiveBuffer[] activeCopy;

        synchronized (mLock) {

            mRotateIsScheduled = false;

            scheduleRotateLocked();

            for (ActiveBuffer active : mActive) {

            activeCopy = mActive.toArray(new ActiveBuffer[0]);

        }

        for (ActiveBuffer active : activeCopy) {

            try {

                active.mCallback.onRotateGraphicsStatsBuffer();

            } catch (RemoteException e) {
@@ -148,7 +154,6 @@ public class GraphicsStatsService extends IGraphicsStats.Stub { 
                        active.mInfo.packageName, active.mPid), e);

            }

        }

        }

        // Give a few seconds for everyone to rotate before doing the cleanup

        mWriteOutHandler.sendEmptyMessageDelayed(DELETE_OLD, 10000);

    }