+31
−26
+4
−1
Loading
Donate to e Foundation | Murena handsets with /e/OS | Own a part of Murena! Learn more
rprichard@ pointed out a bug where LogBufferElement::setDropped() reallocates mMsg to the size of mMsgLen in the case where getTag() != 0. However, mMsgLen is in a union with mDroppedCount and mDroppedCount is the value used when a message is already dropped. Therefore, it's possible that logd uses the wrong value and allocates much more memory than intended. We do call setDropped() on elements that have already been dropped in LogBufferElementLast::coalesce(), so this is not a superfluous issue. To simplify this even more, this code puts an mTag in a union with mMsg, such that if mDropped is true, there will never be an allocated message; mTag will be directly referred to instead. This also reduces the number of allocations needed very slightly. Test: logd/liblog/logcat unit tests. Change-Id: Ia1bfba076439fe31c745a243283d41902bca45ac