summaryrefslogtreecommitdiff
path: root/logd/LogBufferTest.cpp
AgeCommit message (Collapse)Author
2020-10-08Remove liblog, logcat, logd, logwrapperBaligh Uddin
These subdirectories have moved to platform/system/logging. BUG: 168791309 Test: Local build + TH Change-Id: Iaee2ff59d4450f3e59dc9ea8b0e257b2de53e478
2020-10-07logd: single std::mutex for locking log buffers and tracking readersTom Cherry
There are only three places where the log buffer lock is not already held when the reader lock is taken: 1) In LogReader, when a new reader connects 2) In LogReader, when a misbehaving reader disconnects 3) LogReaderThread::ThreadFunction() 1) and 2) happen sufficiently rarely that there's no impact if they additionally held a global lock. 3) is refactored in this CL. Previously, it would do the below in a loop 1) Lock the reader lock then wait on a condition variable 2) Unlock the reader lock 3) Lock the log buffer lock in LogBuffer::FlushTo() 4) In each iteration in the LogBuffer::FlushTo() loop 1) Lock then unlock the reader lock in FilterSecondPass() 2) Unlock the log buffer lock to send the message, then re-lock it 5) Unlock the log buffer lock when leaving LogBuffer::FlushTo() If these locks are collapsed into a single lock, then this simplifies to: 1) Lock the single lock then wait on a condition variable 2) In each iteration in the LogBuffer::FlushTo() loop 1) Unlock the single lock to send the message, then re-lock it Collapsing both these locks into a single lock simplifes the code and removes the overhead of acquiring the second lock, in the majority of use cases where the first lock is already held. Secondly, this lock will be a plain std::mutex instead of a RwLock. RwLock's are appropriate when there is a substantial imbalance between readers and writers and high contention, neither are true for logd. Bug: 169736426 Test: logging unit tests Change-Id: Ia511506f2d0935a5321c1b2f65569066f91ecb06
2020-08-03liblog: don't cache property size values and move to own fileTom Cherry
Don't cache the property size values since they're only queried at the start of logd and only once during dumpstate. Initializing SerializedLogBuffer, which includes all of the logd queries, takes under 100us without the cache, certainly fast enough that this cache is unneeded. Move these functions to their own file in preparation for removing them from liblog. Test: log sizes set appropriately Change-Id: I15a2fd687dcffb4eab2f22ee0825ca86e40cdba3
2020-06-12logd: add a SerializedLogBuffer suitable for compressionTom Cherry
Initial commit for a SerializedLogBuffer. The intention here is for the serialized data to be compressed (currently using zlib) to allow for substantially longer logs in the same memory footprint. Test: unit tests Change-Id: I2528e4e1ff1cf3bc91130173a107f371f04d911a
2020-06-11logd: add a test for clearing logs with a reader presentTom Cherry
Test that: 1) Logs are cleared 2) More logs can be added after clear 3) Well behaving blocking readers stay connected and can read new logs after clear. Test: this unit test Change-Id: I8497896f5fb068b1e50ff0dcaab1cf79aebae2bb
2020-06-03logd: use libbase loggingTom Cherry
We can use libbase logging to output to the kernel log instead of the 'prdebug' function, so use that instead. Bonus #1: we can now use CHECK(). Bonus #2: logging unit tests automatically output to stderr. Bonus #3: We see dependent library's logs instead of losing them to the void. Test: logging unit tests Test: logs show appropriately in dmesg / stderr Test: CHECK() works Change-Id: I92f8056b4820dc4998996cf46460568085299700
2020-06-02logd: move leading_dropped logic into FlushTo()Tom Cherry
This logic isn't generic, so it should not be in the generic LogReaderThread. Moreover, it's currently broken in essentially every case except when filtering by UID, because it runs as in the filter functions before the actual filtering by pid/etc takes place. For example, when filtering by pid, it's possible to get leading chatty messages. The newly added test was failing previously but is fixed by this change. It's fundamentally broken in the tail case. Take this example: 1: Normal message 2: Chatty message 3: Normal message 4: Normal message If you read that log buffer with a tail value of 3, there are three possible outcomes: 1) Messages #2-4, however this would include a leading chatty message, which is not allowed. 2) Messages #3-4, however this is only 2, not 3 messages. 3) Messages #1-4, however this is 4, more than the 3 requested messages. This code chooses 2) as the correct solution, in this case, we don't need to account for leading chatty messages when counting the total logs in the buffer. A test is added for this case as well. Test: new unit test Change-Id: Id02eb81a8e77390aba4f85aac659c6cab498dbcd
2020-06-01logd: create FlushToState classTom Cherry
ChattyLogBuffer::FlushTo() needs an array of pid_t's to differentiate between deduplication and spam removal chatty messages, but that won't be useful to other log buffers, so it doesn't deserve its own entry in the abstruct LogBuffer::FlushTo() function. Other log buffers may need their own data stored for each reader, so we create an interface that the reader itself owns and passes to the log buffer. It uses a unique_ptr, such that the when the reader is destroyed, so will this state. FlushToState will additionally contain the start point, that it will increment itself and the log mask, which LogBuffers can use to efficiently keep track of the next elements that will be read during a call to FlushTo(). Side benefit: this allows ChattyLogBufferTests to correctly report 'identical' instead of 'expired' lines the deduplication tests. Side benefit #2: This updates LogReaderThread::start() more aggressively, which should result in readers being disconnected less often, particularly readers who read only a certain UID. Test: logging unit tests Change-Id: I969565eb2996afb1431f20e7ccaaa906fcb8f6d1
2020-06-01logd: fix bug in FlushTo when requesting exact sequence numberTom Cherry
SimpleLogBuffer::FlushTo() attempts to find the iterator matching a given sequence number, but the logic is wrong and will always skip one element forward. This change fixes this and adds a test for the situation. This likely contributed to some test instability in the past, but was identified because subsequent changes that track the start value closer exacerbated this issue. Test: existing and new unit tests Change-Id: Iba2e654e94234693dba20d4747a60bc79d195673
2020-05-21logd: create SimpleLogBuffer and implement ChattyLogBuffer in terms of itTom Cherry
Test: unit tests with SimpleLogBuffer Change-Id: If6e29418645b5491df9b8aeef8f95bb786aeba93
2020-05-21logd: separate Chatty only vs generic LogBufferTestsTom Cherry
Separate these tests such that future log buffer implementations can be run against the generic tests. Use a parameterized fixture to allow testing any number of log buffers. Test: these unit tests Change-Id: I6d90838e8efa019b934d08da25cab0c2405b66cd
2020-05-20logd: add tests for log deduplicationTom Cherry
Fix a subtle bug that liblog event messages have a payload of int32_t, not uint32_t, so they should only be summed to int32_t max. Make a bunch of test improvements as well to support these. Test: these tests Change-Id: I4069cc546240bfffec5b19f34ebec913799674e8
2020-05-18logd: build liblogd and its test on hostTom Cherry
Plus the various fixups needed for building on host. Test: run these tests on host Change-Id: I85e6c989068f80c5a80eaf5ad149fdad0a045c08
2020-05-18logd: add LogBufferTest.cppTom Cherry
Add a standalone test of log buffers that does not interact with the logd running on the device. Test: this new test Change-Id: Ie4ecc50289ef164aa47cc72ddeeb9b28e776db94