Logs
Home > What does the bugreport report contain
ChkBugReport currently extracts the system, main and kernel logs, and does some processing as well.
Here is a simple example: http://sonyxperiadev.github.com/ChkBugReport/examples/bugreport_aidldeadlock_out/data/f00047.html#ch606
- As a first step, there is a simple coloring, based on the error level. Also the pids are converted to links, so you can find the logging process easily.
- Launching of activities are detected and marked with a sidenote:
- Also detected exceptions, ANRs and configuration changes (e.g. rotating the phone) are marked in a similar way.
- Create a spam toplist (shows which applications are producing most of the logs): http://sonyxperiadev.github.com/ChkBugReport/examples/bugreport_aidldeadlock_out/data/f00048.html#ch667
- Create a log level distribution table, which shows how many log lines of different error levels there are: http://sonyxperiadev.github.com/ChkBugReport/examples/bugreport_aidldeadlock_out/data/f00050.html#ch669
- Create memory usage graphs for each process:
The event log format is more strict, and thus much better to process, thus more information can be extracted from it. Some of the information is similar to the system log:
- The log lines are highlighted just like for the system log
- The detected ANRs are also marked at the side
- Memory usage is also extracted in a similar way
- Spam top list is also created
However there are some extra information as well:
Every time an activity is started, android logs how much time it needed to start up. These logs are extracted and added into a table (which can be sorted easily, by just clicking on the headers): http://sonyxperiadev.github.com/ChkBugReport/examples/bugreport_deadlock_out/data/f00059.html#ch647
Every time a database is read or written, or a content prover is queried or updated, android measures the time it took to execute the operation. Since there are many database access, android cannot log each of them, so instead it calculates a probability from the execution time. For example if the threshold is 500ms, then every access which takes at least 500ms will be logged. If an operation takes 250ms, then there is a 50% chance that it will be logged.
ChkBugReport then extracts these logs (which contain a subset of the accesses) and creates both statistics (http://sonyxperiadev.github.com/ChkBugReport/examples/bugreport_deadlock_out/data/f00061.html#ch657) and charts from it:
Then you can use this information to find applications which are writing to the database too often, and thus making the phone slow.
Note: These charts are created twice. In both cases the timeline is shown on the X axis. The version shown above contains a row for each process, the bars show the time and length of the operation. The color of the bar depends on the calculated percentage.
In the other version (shown below) all the bars are shown together, the Y axis shows the calculated percentage and there is a color allocated for each process:
Similar to content updates and queries, some other operations are also measured and logged with a calculated probability:
- dvm_lock_sample charts can show when an object is locked for too long:
- binder_sample charts can show when an AIDL call takes too long time:
![binder_sample chart] (http://sonyxperiadev.github.com/ChkBugReport/examples/bugreport_aidldeadlock_out/data/sample_graph_binder_sample_alt___alt.png)
Note that the binder charts are created twice: once for the calling process and once for the interface name
The tool extracts all activity and service lifecycle events and shows it in a table: http://sonyxperiadev.github.com/ChkBugReport/examples/bugreport_deadlock_out/data/f00065.html
Note: the table rows can be re-ordered by dragging them.
The color coding is the following:
- white means the process was not running
- light red shows when the process was alive
- dark red shows when the service/activity as in the created state
- green shows when the activity was resumed
- yellow is used to mark areas where there are too many changes to show and it doesn't fit in the chart
Similarly to the above, statistics are also created from the data, so one can see how often was a service/activity in the memory: http://sonyxperiadev.github.com/ChkBugReport/examples/bugreport_deadlock_out/data/f00066.html#ch699
Note: You can sort the table by clicking on the columns. However when you want to sort on time, don't sort of the formatted time (e.g. 2m42s98ms) but instead sort on the millisecond time.
Since several services and activities can run in the same process, one extra service does not always have a big impact on memory. An extra linux process can. So the tool creates a similar statistics based on process starts/kills: http://sonyxperiadev.github.com/ChkBugReport/examples/bugreport_deadlock_out/data/f00067.html#ch702
An interesting column to look at is the "Restart after kill count". This will show how many times a process was restarted after being killed due to too many background processes. The "Avg restart after kill time" shows the average time. If this value is below 60 seconds (60000 milliseconds) then it means the processes was restarted within a minute, which means the system has too many background processes which play ping-pong with each other.