Devices like dory get slammed when bugreports are taken and can't
compress all the raft logs in the current 5min timeout. Our dogfooders
spend their precious time getting us bugreports and then we can't act
on them because we have broken raft logs. :(
This change bumps up the timeout in the hopes that we can get complete
logs from even our slowest devices.
Change-Id: I10741a6185b39544f4c0531f0ee74864d74a1aa4
Also, move NetworkDiagnostics between the two runs of getting the
wifi counters, so we can see the effect on the counters of
sending our probe packets.
Bug: 23661687
Change-Id: I3f81c003a35f50ac1cb8e77d0a8c73dae4fd91f3
(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
Use the native stack dumping functions that allows time outs. If
debuggerd locks up, before a bugreport would hang forever. Now
it will timeout properly and still get all of the other information.
Bug: 18766581
(cherry picked from commit 457731f69e)
Change-Id: I39e8e9c60209e3ef9efac795fedb8e1edce2bd3e
Use the native stack dumping functions that allows time outs. If
debuggerd locks up, before a bugreport would hang forever. Now
it will timeout properly and still get all of the other information.
Bug: 18766581
Change-Id: I85053b8dcfe6224e2b64b4d8f7f2ef448b3cda34
The previous version printed out the nanoseconds elapsed, not seconds.
Bug: 18766581
(cherry picked from commit 67c5a8af9e)
Change-Id: Icbaaee83a92767694fd98e3c790f36f4d24681b0
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
The clock() function returns the processor time used by the process. This
is not a good timeout mechanism since the code is suspended most of the
time waiting for the forked process to finish. Replace with the time()
function.
Bug: 17154069
Change-Id: Ib383329f9db269445d71a100553b08e71fddda3f
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
dumpstate was not dumping any stack traces for vm processes because
it was failing the string compare for /system/bin/app_process.
64-bit devices use app_process32 and app_process64 instead of
app_process, and zygote64 alongside zygote. Change the string
matching to be prefix matching.
(cherry picked from commit 8eb25d552b)
Change-Id: I6b1568161fae278f0e6107990e5b750cf0ca902b
