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

Commit ab4d2683 authored by Narayan Kamath's avatar Narayan Kamath Committed by Caleb Xu
Browse files

Binder: Be forceful about a forceful exit 

We were previously using exit(1) when code servicing an IPC threw
any subclass of Error. That made it much harder to diagnose cases
where that happened because :

- exit runs global destructors, which might prove problematic (see
  linked bug).
- such exits are often due to bugs in application code (things like
  AssertionErrors being thrown) but aren't flagged as such by our
  infrastructure, or by humans for that matter.

To address both issues, use FatalError() so that the runtime can dump
more useful information to the logs before it aborts.

Test: manual
Bug: 36813403
Change-Id: I5826090229109dc7cb19f0c3571c609f990cd36a
(cherry picked from commit d64abfcf)
parent 260e7f3f

core/jni/android_util_Binder.cpp

+3 −9
Original line number Diff line number Diff line
@@ -192,18 +192,12 @@ static void report_exception(JNIEnv* env, jthrowable excep, const char* msg) 


    if (env->IsInstanceOf(excep, gErrorOffsets.mClass)) {

        /*

         * It's an Error: Reraise the exception, detach this thread, and

         * wait for the fireworks. Die even more blatantly after a minute

         * if the gentler attempt doesn't do the trick.

         *

         * The GetJavaVM function isn't on the "approved" list of JNI calls

         * that can be made while an exception is pending, so we want to

         * get the VM ptr, throw the exception, and then detach the thread.

         * It's an Error: Reraise the exception and ask the runtime to abort.

         */

        env->Throw(excep);

        ALOGE("java.lang.Error thrown during binder transaction (stack trace follows) : ");

        env->ExceptionDescribe();

        ALOGE("Forcefully exiting");

        exit(1);

        env->FatalError("java.lang.Error thrown during binder transaction.");

    }



bail: