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

Commit b919c242 authored by Chavi Weingarten's avatar Chavi Weingarten
Browse files

Fixed issues with transaction synchronization in VRI

There were several crashes in transaction native code that was a result
of unsynchronized access. This was due to VRI posting the completed
transaction onto a new thread without first copying it. When this
occurs, a timeout can be invoked and modify the same transaction without
holding a lock. This fix ensures the transaction is merged (and
therefore cleared) to a local reference before posting the message to
ensure it's no longer using the transaction that requires the lock.

This also exposed an issue with the logic around checking if it's a
client side VRI or system side. The crash should only have occurred in
system server since non system server VRI shouldn't post the final
transaction onto the message queue and therefore are holding the lock.
This CL also fixes that logic to ensure that in non system server VRI's
we don't post to the message queue since it's not needed.

Test: Added logs in VRI to ensure the only posting to queue in system
server
Bug: 302686733

Change-Id: I58539a81b5150af07e2f47e912885e6978d0eeec
parent a891bc20
Loading
Loading
Loading
Loading
+8 −2
Original line number Original line Diff line number Diff line
@@ -3963,9 +3963,15 @@ public final class ViewRootImpl implements ViewParent,
            // on a different thread. However, when the current process is system, the finishDraw in
            // on a different thread. However, when the current process is system, the finishDraw in
            // system server will be run on the current thread, which could result in a deadlock.
            // system server will be run on the current thread, which could result in a deadlock.
            if (mWindowSession instanceof Binder) {
            if (mWindowSession instanceof Binder) {
                reportDrawFinished(t, seqId);
                // The transaction should be copied to a local reference when posting onto a new
                // thread because up until now the SSG is holding a lock on the transaction. Once
                // the call jumps onto a new thread, the lock is no longer held and the transaction
                // send back may be modified or used again.
                Transaction transactionCopy = new Transaction();
                transactionCopy.merge(t);
                mHandler.postAtFrontOfQueue(() -> reportDrawFinished(transactionCopy, seqId));
            } else {
            } else {
                mHandler.postAtFrontOfQueue(() -> reportDrawFinished(t, seqId));
                reportDrawFinished(t, seqId);
            }
            }
        });
        });
        if (DEBUG_BLAST) {
        if (DEBUG_BLAST) {