54bcc5ffd5
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 |
||
|---|---|---|
| .. | ||
| Android.mk | ||
| dumpstate.c | ||
| dumpstate.h | ||
| libdumpstate_default.c | ||
| utils.c | ||