Otherwise, ueventd's oom_adj value would have been 0 and it could
easily get killed early during low memory events
Change-Id: I1adbd18c37215b26ae77e70f7b8dbd1e143fc2d4
Signed-off-by: Dima Zavin <dima@android.com>
The class_reset command used to reset services that had been set to
"disabled" in the init.rc file to a non-disabled state. Now, if the
service was originally set to "disabled", have the reset command set
it back to disabled. Otherwise, set it to the "reset" state as it
currently does.
Change-Id: I0c10582e46a8e443d4748d9d893ae762b19b653a
Dump some memory at addresses for all registers that look like they
might have valid addresses. Previously this was only done for PC
and LR.
(This is expected to be disabled before ship.)
Bug 5484924
Change-Id: I9802eaa396783e1286ae0c53eaf2473892c38a02
When the tombstones are uploaded to APR, they're truncated at 64KB.
This causes the log data, which is at the end, to be lost if the
process has more than about 12 threads (which many do).
This change adds the last few lines of the log right below the
report for the crashing thread, where we should be guaranteed to
keep it.
Also, clean up trailing newlines on log messages (which end up in
the tombstone), and don't print a "------- log" banner if there
aren't any messages in that log file (e.g. slog).
Also also, don't try to show_nearby_maps unless this is the crashing
thread.
Bug 5471955
Change-Id: Iaa4fd2fafbaeda2f20bb95f202177d7744a91f9d
This makes two changes:
(1) Display ASCII values next to the memory dumps. For example:
I DEBUG: 00008ac4 706f6f4c 20676e69 74206425 73656d69 Looping %d times
I DEBUG: 00008ad4 7453000a 6e69726f 6f742067 0a702520 ..Storing to %p.
I DEBUG: 00008ae4 65642f00 657a2f76 55006f72 6c62616e ./dev/zero.Unabl
(The hex values are still displayed as little-endian word values, while
the ASCII part is byte oriented.)
(2) Optionally display memory dumps for all registers, not just LR
and PC, for the crashing thread. This is meant for situations where
we crash dereferencing foo->bar and want to see what the memory near
"foo" looks like -- could be handy if it got stomped by MUTF-16 text
or something recognizable.
Change #2 is currently disabled, via a compile-time setting.
Bug 5471955
Change-Id: Iacfd01c314055bad81db2f43b7d239f10086fcfb
Testing:
The following test cases all passed and generated log entries:
# echo -n '\03foo\0bar\0' > /dev/log/main
# echo -n '\03\0bar\0' > /dev/log/main
# echo -n '\03\0a\0' > /dev/log/main
The following entries were successfully processed by
logcat but produced no log entries:
# echo -n '\03\0\0' > /dev/log/main
# echo -n '\03a\0\0' > /dev/log/main
# echo -n '\03b\0\0' > /dev/log/main
Also tested the pathological error condition:
cat /dev/urandom > /dev/log/main
which produced many "+++ LOG: malformed log entry" errors.
Bug: 5478600
Change-Id: I53bc79507242dcfc14445746c29edf47be0a90b4
Sanity check that the length we get back from the kernel matches
how much data we actually received.
Change-Id: I5cfd80321ab41459bb514dfde2da57413a7bd9e6
When parsing log entries which may have embedded \0s, it's
possible for entry->messageLen to not be the actual
length of the string in entry->message. Detect this condition.
Bug: 5417417
Change-Id: I712cac7696af7831e24765b5a1b345d6ff5fb407
The Android Problem Report site shows tombstones uploaded from
devices. We can see the native stack traces for every thread,
but sometimes there's a very important bit of information sitting
in the log, and without it we can't analyze the failure.
This change modifies debuggerd so that the log contents for the
crashing process are appended to the tombstone. The format matches
the output of "logcat -v threadtime". Both "system" and "main" logs
are included (but not interleaved -- we're not that fancy).
This feature is only enabled when the "ro.debuggable" system property
is set to 1 (indicating a development device).
Bug 5456676
Change-Id: I3be1df59813ccf1058cec496a906f6d31fbc7b04
Dima Zavin