logger_entry has a hdr_size field meant for backwards compatibility,
however there are a few checks that expect it to be a specific size.
More problematically, it has a variable length array element, msg[0]
at the end, that would be incorrect if the header size was not kept
static.
This change fixes up those issues to facilitate future additions.
Bug: 119867234
Test: logging works with extended size headers, logging unit tests
Test: newly added unit tests with extended size header
Change-Id: I14b2b0855d219d11f374b53a5aa8e05cd6a65eef
/sys/class/power_supply/*/current_now should return uA and the HAL
expects uA too.
Test: VtsHalHealthV2_0TargetTest
Bug: 136717180
Change-Id: I675be1ae645413b9494af4a5d49955aad5bd4f2e
(cherry picked from commit e5bd5f914f)
Merged-In: I675be1ae645413b9494af4a5d49955aad5bd4f2e
There was an email thread about this recently, and I've been asked many
times.
For instance, if this error wasn't attributed, denials a service is
hitting would be attributed to init, and that's a recipe for disaster.
Secondarily, thinking about SELinux whenever you write a new service is
good.
Bug: N/A
Test: N/A
Change-Id: Ib9d2c5d8947375a0d4c33ecf3d075caef6b41f70
* changes:
logd: don't send logs before the start time on the first flushTo()
Revert "logd: drop mSequence from LogBufferElement"
Revert "logd: regression in handling watermark boundary."
Revert "logd: logcat --clear respect pruneMargin"
logd: wait for timeout via CLOCK_MONOTONIC
Revert "logd: wakeup wrap timeout if realtime changes drastically"
logd: do not attempt to sort log messages by time
Logs in logd's buffer are not in time order.
If a client connects and requests logs from a given timestamp, we
start at the beginning of the buffer and find the first entry that has
happened since that timestamp and use its sequence number to flush
logs from. This ensures that we get all logs accumulated in the
buffer since that time stamp and not just the most recent.
However there may be other logs in the buffer that happened before the
timestamp and have likely been already served to the client, therefore
we do not flush those.
We only do this for the first flush, since once we have flushed all of
the logs in the buffer, if another log comes in with a timestamp
earlier than the requested timestamp, it must be out of order and not
seen yet, since it is new even to logd.
Note! This is still broken. There is a race that logs before the
timestamp may come in out of order since the last time the client
disconnected and before it reconnects. The *only* solution to this
problem is that clients need to request logs after a given sequence
number. That will be done as a separate liblog API change, while
these changes put in the ground work to make that possible.
Note 2: the security log implementation, which is one of the most
important users of this, already captures logs from seconds before the
last previous log to work around issues with timestamps. That
workaround mitigates the above issue.
Test: logs work with logcat -t
Change-Id: If1a62a90c082d98c4cf2eb5c92ae3b7e89850cf2
This reverts commit 5a34d6ea43.
There is a long standing bug that logd will leak memory during its
prune process if the time on the device changes significantly forwards
then backwards. This is due to using the timestamp of each log
message to determine what log messages are yet to be processed by a
reader thread.
Various attempts have been made to rectify this, but the only solution
that safely fixes this issue is to go back to using sequence numbers
on the log messages.
Bug: 64675203
Bug: 77971811
Bug: 149340579
Bug: 150923384
Test: logcat output looks sane
Change-Id: Ibce79cf184eb29a4914f3e42a8cb2868d04dc165
This reverts commit 0878a7c167.
This is a partial revert of the above commit. It simply removes
pruneMargin from these calculations since it is going away.
Bug: 149340579
Test: --clear works well
Change-Id: I1763be56fae7052058a800fad3b295c73cdcadf6
/sys/class/power_supply/*/current_now should return uA and the HAL
expects uA too.
Test: VtsHalHealthV2_0TargetTest
Bug: 136717180
Change-Id: I675be1ae645413b9494af4a5d49955aad5bd4f2e
Crc calculation shows up in the profiler in 2-5% range, and is
never currently validated. Let's disable it for good.
For a well-compressible test data the difference is even nicer:
Benchmark Time CPU Iteration
------------------------------------------------------------------
ziparchive-benchmarks:
before:
#ExtractEntry/2 1943244 ns 1926758 ns 375
#ExtractEntry/16 1877295 ns 1867049 ns 375
#ExtractEntry/1024 1888772 ns 1879976 ns 373
after:
#ExtractEntry/2 817003 ns 812870 ns 874
#ExtractEntry/16 814029 ns 809813 ns 875
#ExtractEntry/1024 804904 ns 800972 ns 879
Bug: 153392568
Test: atest, manual
Change-Id: I917abecab01301f1d09a5bf3b542d24b3875e359
am skip reason: Change-Id I7636bb5958ed10ae9a66015f04f168129618272f with SHA-1 4c59323dc6 is in history
Change-Id: Id9766ff43a02a7619cfc928a41e73e00814d8652
This test is killing critical device services, and if it runs
repeatedly or some of the critical services have already died, it'll
force the device to reboot again and potentially consider the test a
failure.
This forces the test to reboot first, so that it is in a fresh state and
we can avoid this type of flake on the device.
Bug: 153444614
Test: atest init_kill_services_test
Change-Id: Ia81a319af1d209f58e70f824bb8eb7f11973637c
There are well known issues with CLOCK_REALTIME jumping drastically.
Test: --wrap works successfully
Change-Id: I5676274783ac9aa9374d2b9254e0109d883cc5a8
This reverts commit 5e001776f4.
The next commit will use CLOCK_MONOTONIC for the timeout, so changes
to CLOCK_REALTIME will no longer be an issue.
Test: logcat output looks sane
Change-Id: I84e5b2db3c25ea6a7024557dba7fa6cc8c9237e5
In recovery mode, load modules from modules.load.recovery if it
exists. Otherwise load from modules.load as usual.
Bug: 150825361
Change-Id: I7636bb5958ed10ae9a66015f04f168129618272f
Merged-In: I7636bb5958ed10ae9a66015f04f168129618272f
Sorting does not work in all cases:
* It only sorts messages up to 5 seconds backwards in time
* CLOCK_REALTIME, which is used as the time that is sorted, can jump
drastically
* Buffers are not sorted if there is a reader holding a region lock
Removing sorting entirely will give more consistent behavior from
logd.
Test: logcat still seems sane
Change-Id: I0923ab2fb377cda941c1e4972689df46f395ac99
The marked library(ies) were available to the APEXes via the
hand-written whitelist in build/soong/apex/apex.go. Trying to remove the
whitelist by adding apex_available property to the Android.bp of the
libraries.
Bug: 150999716
Test: m
Change-Id: I8fd2a3c9b69454c6018c72f5198898bc90dc4d0d
The marked library(ies) were available to the APEXes via the
hand-written whitelist in build/soong/apex/apex.go. Trying to remove the
whitelist by adding apex_available property to the Android.bp of the
libraries.
Bug: 150999716
Test: m
Change-Id: Id08058f3105463558c6c82298344a33af0efb2d3
If the Dex file we're trying to examine is already within the unwinder's
address space, we don't need to load it from disk or copy it across
processes.
This avoids using up virtual address space to map in dex files, and
also should be a bit faster to read since it won't go out to the file.
Patch by Chris Sarbora
Test: Ran new unit tests.
Test: Ran 137-cfi art test.
Change-Id: I949457856f051cca11b9020e9da3a41bbf6e5c8e
am skip reason: Change-Id I810bb7e085b9b8648858de1a02165162d1fd163e with SHA-1 539b98fb58 is in history
Change-Id: I512f03b8378164b52b0d126e92df33909ecd7abc
