logd: iterator corruption paranoia
Add checking for impossible(tm) scenarios within LogBuffer::flushTo: 1) When iterating through the log entries, check if the iterator returns two identical element references and break out of the loop. 2) Cap the maximum number of log entries we will skip while holding the iterator lock at 4194304, break out of the loop. We print a message to the kernel logs if we hit these cases. ToDo: Remove this paranoia at some future date. Test: gTest liblog-unit-tests logcat-unit-tests and logd-unit-tests Bug: 37378309 Change-Id: I789594649db14093238828b9f6d1daeca8b780c2
Loading
Please register or sign in to comment