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
for_each_pid only finds processes and not their threads. Add
for_each_tid and call it for show_wchan so we can see where all
threads are blocked in the kernel.
Change-Id: Iffb59f7c2933cecf51cdd358a36e19932c2f24c7
