Revert submission 3062926
Reason for revert: We want guest state to be present in all threads - revert to be able to fix the proto field type.
Reverted changes: /q/submissionid:3062926
Change-Id: I32b745cca95a619b78bdce0a7d948ac479d42f21
Revert submission 3062926
Reason for revert: We want guest state to be present in all threads - revert to be able to fix the proto field type.
Reverted changes: /q/submissionid:3062926
Change-Id: I87b282a0d9caebe4eae2e7d8eca8ec8ebaa3eca6
This CL is to get guest registers information.
Bug: b/321799516
Test: m
Testing for TLS Slot:
Manual testing by: 1. crash the jni tests to produce tombstones file 2.
get the signature field of guest state header 3. verified it is the same
value as NATIVE_BRIDGE_GUEST_STATE_SIGNATURE
Manual test the arm64 by: 1. flash build to pixel phone and verify
retrieving TLS_SLOT_THREAD_ID's tid field is the same as current thread
id.
Testing for register values:
Test and print out registers values for riscv64, looks make sense that
has null zero value slots.
Change-Id: Iff44ac5c2b202e44f3fb4e6909fbea141e54ae6b
Rather than have to create a number of #if defines for the memory
dumping parts of the tombstone, create a single function to generate
these strings for the memory tests.
Make CrasherTest.smoke use a regex that passes on 32 bit and 64 bit.
Make the tests page size agnostic.
Bug: 339017792
Test: Treehugger.
Test: Ran 32 bit and 64 bit versions of tests on a real device.
Test: Ran on the aosp_cf_x86_64_phone_pgagnostic-trunk_staging-userdebug
Change-Id: If9365061b85de23b00a1bf947d85923cde06c068
Now that Android devices can use 16k page size, it's important that we
know what configuration the device is in when see issues.
1) If the device is in 4k mode, we see nothing new.
2) If the device is in 16k mode, we see this line in the tombstones:
Page size: 16
3) If the device is in 4k mode, but was previous in 16k mode we see:
Has been in 16kb mode: yes
Test: atest debuggerd_test
Test: atest debuggerd_test with ro.misctrl.16kb_before="1"
Test: adb shell cat /data/tombstones/tombstone_00
Bug: 335247092
Change-Id: If7ca3b0954a01070ff413758296460ca1d023ca5
Add signo for target thread in fallback path;
Update test for seccomp tombstone thread abort.
Bug: 336946834
Test: debuggerd_test
Test: Send fatal signal to process with NO_NEW_PRIVS
Change-Id: Ie9d77a93da9cd89ab7093b8949f311e03d96ec50
The malloc_not_svelte variable name is confusing and makes the
low memory config the default. Change this so that the default is
the regular allocator, and that Malloc_low_memory is used to enable
the low memory allocator.
Update blueprint rules so that scudo is the default action.
Test: Verified scudo config is used by default.
Test: Verfified Android GO config uses the jemalloc low memory config.
Change-Id: Ie7b4b005a6377e2a031bbae979d66b50c8b3bcdb
Two things need changing for debuggerd_test to pass.
1. The seccomp policy needs to allow for PROT_MTE (0x20) in both
mprotect() and mmap(). Stack MTE processes do a mprotect()/mmap() of
the stack when launching a process.
2. The fault address and stack pointer need to be untagged when trying
to figure out the stack overflow cause.
Bug: 320448268
Bug: 292478827
Test: atest debuggerd_test --iterations=10
Change-Id: I56471c32ca40edffbb61b7547bdf2b85a6eb1ff7
This is a no-op but will be used in upcoming scudo changes that allow to
change the depot size at process startup time, and as such we will no
longer be able to call __scudo_get_stack_depot_size in debuggerd.
Bug: 309446692
Change-Id: Ib64b9d042b2a2088484ec5e61944c089a1d85314
This is done so that we could depend on it elsewhere without needing all the unrelated methods.
Needed for ag/24553347
Bug: 296207744
Test: refactoring build
Change-Id: I7c6733208f3ae63ba9559753a24cffcb8e1b9d1e
This is a no-op but will be used in upcoming scudo changes that allow to
change the depot size at process startup time, and as such we will no
longer be able to call __scudo_get_stack_depot_size in debuggerd.
We already did the equivalent change for the ring buffer size in
https://r.android.com/q/topic:%22scudo_ring_buffer_size%22
Bug: 309446692
Change-Id: I761a7602c54a1f8f2d0575c5e011820d8dbaab63
The only way to get a bad architecture value in the protobuf is if
the data was corrupted or an unsupported architecture was added without
the register support.
If the protobuf is corrupted, this is strictly better since it
still produces a tombstone with the data present.
If there is an unsupported architecture, it will still result in a tombstone,
only the registers would not be present. It would also be very obviously
a problem that needs to be fixed. Again, this is strictly better since
the crash in generation is not necessarily visible unless you look at
the log. Here, the data is in the log and in the tombstone.
This also removes the only dependency in this file on the async_safe
library.
Test: Ran unit tests.
Test: Forced an invalid architecture and verified tombstone is present
Test: with error message, and error message printed in the log.
Change-Id: I8e4a2e3f778fafb5b7241c2f23d5f867f1341ed8
The new 6.6 kernel headers added a new segv type, SEGV_CPERR. Add this
to the switch statement.
Test: Unit tests pass.
Change-Id: I77eb4748e51c7e7d7291bfd2180b0ccb3b5a6ded
Check for the log opening failing.
Add the ability to put error messages in the log and tombstone so
that it's clear if the log reading failed in some way.
Adjust test so that if there is a log or if no log exists, the test
will still pass.
Print an <unknown> if the command line is unreadable instead of nothing.
Test: Ran unit tests.
Test: Induced error and verified error message is save in tombstone.
Change-Id: I2fce8078573b40b9fed3cd453235f3824cadb5e3
Some testing environments can have a test that is sending many
thousands of messages to the log. When this type of process crashes
all of these log messages are captured and can cause OOM errors
while creating the tombstone.
Added a test to verify the log messages are truncated. Leaving this
test disabled for now since it is inherently flaky due to having to
assume that 500 messages are in the log.
Added a test for a newline in a log message since it's somewhat
related to this change.
NOTE: The total number of messages is capped at 500, but if a message
contains multiple newlines, the total messages will exceed 500.
Counting messages this way seems to be in the spirit of the cap,
that a process logging a large message with multiple newlines does
not completely fill the tombstone log data.
Bug: 269182937
Bug: 282661754
Test: All unit tests pass.
Test: The disabled max_log_messages test passes.
Change-Id: If18e62b29f899c2c4670101b402e37762bffbec6
Also add new unit tests to verify this behavior.
Bug: 276934420
Test: New unit tests pass.
Test: Ran new unit tests without pthread_setname_np call and verified
Test: the tests fail.
Test: Force crash logd and verify log messages are not gathered.
Test: Force crash a logd thread and verify log messages are not gathered.
Change-Id: If8effef68f629432923cdc89e57d28ef5b8b4ce2
liblog can drop data when debuggerd is overloaded, which leads to
truncated tombstones. by adding the count separately, automation can
easily see whether it is dealing with a truncated tombstone or not.
Bug: 269537146
Change-Id: Ia991537efc0d6b57cbff23ee45af6521467aa20d
When moving to a proto tombstone, backtraces no longer contain
an offset when a frame is in a shared library from an apk.
Add the offset display again if needed, and add a test to
verify this behavior.
Bug: 267341682
Test: All unit tests pass.
Test: Dumped a process running through an apk to verify the offset
Test: is present.
Change-Id: Ib720ccb5bfcc8531d1e407f3d01817e8a0b9128c
An early return out of this function makes it harder to add new prints
after the memory maps.
Test: m, flash, look at tombstone
Change-Id: Id06e432918d69ac3307761b244473b6b7ab769e8
GWP-ASan changed one of the APIs upstream to now take the fault address
as well. This is to support the recoverable mode.
Add the fault address as well.
Test: gwp_asan_unittest
Bug: N/A
Change-Id: I8a4edd3fad159d91cc036050d330bbb8f9c8d435
This is a no-op but will be used in upcoming scudo changes that allow to
change the buffer size at process startup time, and as such we will no
longer be able to call __scudo_get_ring_buffer_size in debuggerd.
Bug: 263287052
Change-Id: I350421d1fcdf22ce3b8b73780b88c1e10fa8a074
Signed-off-by: Liu Cunyuan <liucunyuan.lcy@linux.alibaba.com>
Signed-off-by: Mao Han <han_mao@linux.alibaba.com>
Change-Id: Ie22c2895fc30fab68eddc18713c80e403f44b203
r.android.com/2108505 was intended to fix a crash in Scudo in
the case where the stack depot, region info or ring buffer were
unreadable. However, it also ended up introducing a number of bugs into
the code. It failed to call __scudo_get_error_info if the page at the
fault address was unreadable. This can happen in legitimate crash cases
if a primary allocation was close to the boundary of a mapped region,
or if the allocation was a secondary allocation with guard pages. It
also used long as the type for tags, whereas Scudo expects it to be
char. In combination this ended up causing most of the MTE tests to
fail. Therefore, mostly revert that change.
Fix the original crash by null checking the pointers returned by
AllocAndReadFully before proceeding with the rest of the function.
Bug: 233720136
Change-Id: I04d70d2abffaa35fe315d15d9224f9b412a9825d
