| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
| |
These subdirectories have moved to platform/system/logging.
BUG: 168791309
Test: Local build + TH
Change-Id: Iaee2ff59d4450f3e59dc9ea8b0e257b2de53e478
|
| |
|
|
|
|
|
|
|
| |
SerializedLogChunk.three_logs assumes that log buffers are
zero-initialized, but they are not. This causes test failures on
host.
Test: this test passes
Change-Id: I0dfa282bdc36eaa4e8e39d85c5227f717b45ec2a
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously ClearUidLogs() would Compress() the log buffer in all
cases, however that is the wrong behavior when writer_active_ is true
and would leave the SerializedLogChunk object in an invalid state. If
more logs are written to the log, then write_offset() will be higher
than the compressed size of the log, violating a CHECK() when later
decompressing the log.
This change does not call Compress() in ClearUidLogs() if
writer_active_ is true. It upgrades a check in Compress() from a
simple if statement to a CHECK() to prevent against this happening in
the future.
It adds a test that exercises the previously failing path.
Bug: 166187079
Test: unit tests
Change-Id: Ic5fbcf16f724af1c20170b8f4e6e2daadf6a9529
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When calculating the space used for pruning, if a log chunk is
compressed, that size is used otherwise the uncompressed size is
used. This is intended to reach a steady state where 1/4 of the log
buffer is the uncompressed log chunk that is being written to and the
other 3/4 of the log buffer is compressed logs.
If we wait until there are no readers referencing the log chunk before
compressing it, we end up with 2 uncompressed logs (the one that was
just filled, that readers are still referencing, and the new one that
was allocated to fit the most recent log), which take up 1/2 of the
log buffer's allotted size and will thus cause prune to delete more
compressed logs than it should.
Instead, we should always compress the log chunks in FinishWriting()
such that the compressed size will always be used for log chunks other
than the one that is not actively written to.
Decompressed logs due to readers are ephemeral by their nature and
thus don't add to the log buffer size for pruning.
Test: observe that log buffers can be filled in the presence of a reader.
Change-Id: Ie21ccff032e41c4a0e51710cc435c5ab316563cb
|
| |
|
|
|
|
|
|
|
|
|
| |
A previous change included sizeof(SerializedLogChunk) to the size of a
log chunk to more accurately track logd's log usage, but did not
update the tests that check this value, so this change updates them
appropriately.
Bug: 161179582
Test: logd-unit-tests
Change-Id: Ic37f07fff98c260dcf39b7cc79504c1c3fc2149d
|
|
|
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
|
