logd: clarify release_Locked() for static analyzer
(cherry pick from commit 0ecdec7a0922f5e99569c558fd3c6440b826e583)
release_Locked() is called with a reference count and threadRunning,
the static analyzer can not tell this and estimates that a call to
delete this will occur. So let us invent a new call
release_nodelete_Locked() to ensure it is clear we will not be
arranging a delete this in the context of this code path. The
delete this will follow in the immediate codepath in this function
after threadRunning is cleared, and decRef_Locked() is called.
Change will also remove any developer FUD regarding release_Locked()
usage at this location.
SideEffects: None
Bug: 27434831
Change-Id: I91b060b2dadc72cc449fa381c934afb577bee037
diff --git a/logd/LogTimes.cpp b/logd/LogTimes.cpp
index a4b96d3..2a04880 100644
--- a/logd/LogTimes.cpp
+++ b/logd/LogTimes.cpp
@@ -90,7 +90,7 @@
while(it != times.end()) {
if (*it == me) {
times.erase(it);
- me->release_Locked();
+ me->release_nodelete_Locked();
break;
}
it++;
diff --git a/logd/LogTimes.h b/logd/LogTimes.h
index f5969df..b66ff9e 100644
--- a/logd/LogTimes.h
+++ b/logd/LogTimes.h
@@ -75,7 +75,13 @@
void triggerSkip_Locked(log_id_t id, unsigned int skip) { skipAhead[id] = skip; }
void cleanSkip_Locked(void);
- // Called after LogTimeEntry removed from list, lock implicitly held
+ // These called after LogTimeEntry removed from list, lock implicitly held
+ void release_nodelete_Locked(void) {
+ mRelease = true;
+ pthread_cond_signal(&threadTriggeredCondition);
+ // assumes caller code path will call decRef_Locked()
+ }
+
void release_Locked(void) {
mRelease = true;
pthread_cond_signal(&threadTriggeredCondition);