(cherry pick from commit e3c4df96083231b519dad919fd0ed6624100b368)
- For those that are proud to call themselves logspam police
- Every time someone declares that something is too chatty, or that
they lost their logs because they were declared too chatty and
their associated logs were aggresively pruned we generally
ask them to report the logger statistics to pinpoint what software
product that is the elephant in the room.
- Every time we want to spawn a new 'stop being so spammy' bug spawned
off a bugreport collected for another purpose, we *wish* we had the
logger statistics to help add gravitas to the claim that some piece
of software is the top, or near the top, polluter.
Bug: 22351810
Change-Id: Ifae33cd21d0ae2917a3b4381502d723725b1701c
(cherry pick from commit f989162bb8)
Discover the logcat buffer size, divide by the worst storage
speed in kb/s, and multiply by ten to estimate the timeout in
ms for each named buffer. If that value is less than 20 seconds,
then select 20 seconds. Apply this to each logcat request.
Bug: 21555259
Change-Id: Id36aebff83cb06e94350e4a84fa266b66a8444fc
Bluedroid doesn't have much of a kernel component and no devices
expose a bluedroid node in debugfs.
Change-Id: I5600e88c543a109257d95591704a8f2a7261dfdc
Add O_CLOEXEC to various file descriptor calls, to avoid
leaking file descriptors to dumpstate's child processes.
Bug: 18342188
Change-Id: I74c47a98dfddc29c618067ad53d879b98ed1d87a
Call logcat -L to pull any LAST Android logs. If the kernel is not
configured for PSTORE and PSTORE_PMSG, the hopes are the empty
content will pressure vendors to slice up and configure support.
Change-Id: I5fddfa1e0f59f24fccc30b257ba68af8a8cf8640
It turns out dump_file is used on a number of /proc and system files.
In one case, the read of a file stalled and caused a bugreport to
hang forever. It's still possible if there is a kernel bug that this
could stall forever, but less likely.
Also, change the return type of nanotime to uint64_t.
Testing:
- Created a named fifo and verified that dump_file fails with a timeout.
- Created a large /data/anr/traces.txt to verify that large files still
dump properly and that the additional NONBLOCK parameter doesn't cause
a problem.
- Created a dummy /data/tombstones/tombstone_00 to verify that the
dump of these files still works.
- Compared a dump using the old dumpstate to the new dumpstate to verify
nothing obviously different.
Bug: 19117030
Change-Id: I0d3dd27583c853cdaccd2fd278748cb5f9ccd4fb
This option doesn't work with the current selinux protections and
doesn't serve much of a purpose. You can get the same results running
this:
dumpstate | gzip > /data/local/tmp/dump.txt.gz
Bug: 19271141
Change-Id: Icc76200df33dc708e30c556ec8a0f393f995fe7c
Sometimes dumping threads takes a long time and bugreport times
out. This change will cause us to accept the bugreport socket connection
before dumping threads and should avoid the failed to connect to dumpstate
service problems we've seen.
Bug: 17758374
Change-Id: I80afa0353cf1c340873f481a8d1d7faffff54120
Previously, the vibration was not performed until after stacks
were gathered which takes a long time. Moved the vibration
to happen earlier so we provide better user feedback for the
three-button salute when collecting a bug report.
Deleted some dead code for playing begin/end sounds.
Improved the timing measurement code to help track down why
bug reports are so slow. (They take over a minute now which
can cause us to lose valuable diagnostic information.)
Bug: 17474152
Change-Id: Iac73f7993d7dc85196aad96f459b22fd4a710f94
Leave default signal handler (terminate) for parent process,
add SIG_IGN as signal handler for children and let them
go down when the parent gets SIGPIPE.
Bug: 17109154
Change-Id: Id33db3e97a32f289eb2a9a1a0ca8acbe3dcd285d
1. Explicitly dump IP addresses.
Currently, some IP addresses are dumped using netcfg, but that
only dumps the first IPv4 address on each interface. Instead,
call ip -4 addr and ip -6 addr explicitly to dump all IPv4 and
IPv6 addresses on the system.
2. Disable dumping /proc/net/{ipv6,}route, because:
- We already dump all IPv4 and IPv6 routes in the tables that
we use.
- /proc/net/route is confusing because it only includes routes
in the main table, which are all but unused. It's also in
unreadable host-byte-order hex.
- /proc/net/ipv6_route is confusing because it includes routes
from all tables but does not say what table they are in.
3. Instead of dumping the contents of /proc/net/arp , use
"ip -4 neigh show" and "ip -6 neigh show" to dump the
neighbour caches for both IPv4 and IPv6.
Bug: 16663736
Change-Id: Id3e509b877ab7b00eb2399b6a9868b12245da2f0
This is a duplicate of the associated human-readable dumps
of these services, but much better for automated parsing.
Change-Id: I902b768b03aeac1472f03f96913f9b8ada5dba9c
