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

Commit 68ac25b9 authored by Steven Moreland's avatar Steven Moreland
Browse files

Binder death recipients: clarify comments 

These say "this should not happen" like it is memory
corruption or bad behavior, but code has been relying
on this a long time. Clarify language as it has gotten
out of date over time, and it was confusing me when
I was reading this code.

Bug: 405737267
Test: N/A
Change-Id: Iaa8367ed0313c5fb9410a5f76644d448e9db120a
parent 067a7249

core/jni/android_util_Binder.cpp

+3 −5
Original line number Diff line number Diff line
@@ -679,8 +679,6 @@ public: 


    void warnIfStillLive() {

        if (mObject != NULL) {

            // Okay, something is wrong -- we have a hard reference to a live death

            // recipient on the VM side, but the list is being torn down.

            JNIEnv* env = javavm_to_jnienv(mVM);

            ScopedLocalRef<jclass> objClassRef(env, env->GetObjectClass(mObject));

            ScopedLocalRef<jstring> nameRef(env,
@@ -865,9 +863,9 @@ RecipientList<T>::~RecipientList() { 
    LOG_DEATH_FREEZE("%s Destroy RecipientList @ %p", logPrefix<T>(), this);

    AutoMutex _l(mLock);



    // Should never happen -- the JavaRecipientList objects that have added themselves

    // to the list are holding references on the list object.  Only when they are torn

    // down can the list header be destroyed.

    // RecipientList recipients hold a weak reference to this object. If

    // this list is destroyed first, it means that unlinkToDeath is not

    // called. Warn them.

    if (mList.size() > 0) {

        for (auto iter = mList.begin(); iter != mList.end(); iter++) {

            (*iter)->warnIfStillLive();