The ro.build.version.release property was changed from being the
codename or final name of the current release to be the final name
of the most recent release. Use ro.build.version.release_or_codename
to reconstruct the fingerprint to match what the build system does.
Bug: 158483506
Test: adb shell getprop | grep fingerprint
Change-Id: I3bd992b6f06ff90bb6024253339a2654afa069ee
Convenience API to disable memory mitigations, where we can specify
logging and also have a single place to update once a related bug is
fixed.
Bug: 166675194
Test: use API to disable memory mitigations
Change-Id: I4a3529ea1911925c49e31cc3809c2743e401c196
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
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
The error was meant to imply "without the filename" but (a) that wasn't
spelled out and (b) anyone who did just try the command would probably
be unpleasantly surprised by the massive amount of spam on their
terminal. So give them copy & paste instead.
(I did consider using their supplied filename, but since that's almost
certainly blah.zip, it seemed uncool to silently create a large text
file called "something.zip"!)
Bug: http://b/170225883
Test: untested for lack of a working pre-N device right now
Change-Id: I834939c963ca09927ccd4dc5ed8e88c65455838e
Too many vendors assume that this is included, and it's not worth the
effort to clean up.
Bug: 165825252
Test: build
Change-Id: Ib99f0de4aac64134c21c0ee09f7ea576ebd0fe9e
This accesses shared resources in SerializedLogBuffer and therefore
requires a lock.
Bug: 169736426
Test: malloc_debug_system_tests
Change-Id: I807c65f4719481f933b4917a50f83f933b1929fb
Too many vendors assume that this is included, and it's not worth the
effort to clean up.
Bug: 165825252
Test: build
Change-Id: I42fb32be7e5e3201dfc5c58734e3ef5b9251faf1
Revert "Link to libsnapshot_cow everywhere libsnapshot is linked."
Revert submission 1433573-vab-libsnapshot-linkage
Reason for revert: b/169981170, update crash for droidfooders.
Reverted Changes:
Ie75bba98c:Link to libsnapshot_cow where libsnapshot is linke...
Ieedfadc55:libsnapshot: Partially implement OpenSnapshotWrite...
I28a5d4a88:Link to libsnapshot_cow everywhere libsnapshot is ...
Exempt-From-Owner-Approval: Revert to unblock dogfood
Change-Id: I0677df77672aca9fd54d94e009ac0be7c88a1a9d
Remove WrappedPrivateKey and select wrapped vs plaintext key command
based on format instead.
Bug: 154033394
Test: send wrapped test key. Not yet accepted by trusty
Change-Id: I3b0a29be78f2a8e84ebd990713f66788256d8e3f
Mark a CIE with a S in its augmentation string as signal frame.
This allows the code to properly handle signal frame data if none
of the signal frame pattern matchers work.
For a signal frame, DwarfSectionImpl<AddressType>::Eval needs to
continue the unwinding even if PC is zero. A zero PC means that the
program has crashed, and we should try to recover the real PC using the
return address on the stack or LR. This behavior is tested by
UnwindOffline.signal_{x86,x86_64}, which modify the libc.so files
so that the signal frame pattern matcher fails and the CIE/FDE
data is used instead.
Test: libunwindstack_test
Change-Id: I4655b070028fd984345311a5e743796f8c30ed36
