commit a190ecb6f16b025a9c0c82f4c15ef5f759cd7e97
author Steven Moreland <smoreland@google.com> Mon Oct 21 23:01:56 2024 +0000
committer Steven Moreland <smoreland@google.com> Mon Oct 21 23:18:50 2024 +0000
tree 32d2998080df8cdedc1360a950fb7fde94bc51ff
parent 097b607ac6855b6c81ef4495c3738ba5e2f2c9db

RefBase: document leak memory case

We should fix the leak, but it introduces the possibility
that something is use this. Instead, document best practice
(not to allocate RefBase objects on the stack).

Fixes: 295340906
Test: N/A
Change-Id: Ife7a561f790dc687fb99b73729818e61834fa272

libutils/binder/RefBase.cpp

diff --git a/libutils/binder/RefBase.cpp b/libutils/binder/RefBase.cpp
index 2d2e40b..4291f1e 100644
--- a/libutils/binder/RefBase.cpp
+++ b/libutils/binder/RefBase.cpp
@@ -787,7 +787,7 @@
             // sp<T>(T*) constructor, assuming that if the object is around, it is already
             // owned by an sp<>.
             ALOGW("RefBase: Explicit destruction, weak count = %d (in %p). Use sp<> to manage this "
-                  "object.",
+                  "object. Note - if weak count is 0, this leaks mRefs (weakref_impl).",
                   mRefs->mWeak.load(), this);
 
 #if ANDROID_UTILS_CALLSTACK_ENABLED