Your browser does not support JavaScript!



Wednesday, December 05, 2012
Solve battery and memory problems by analyzing diagnostic data
Solve battery and memory problems by analyzing diagnostic data

Occasionally, your iPhone sends reports with diagnostic information to Apple. You can disable this feature, at least the sending part, but any way reports are being generated. Apple receives this data and analyzes it to find bugs and improve functionality and iOS behavior.

Digging a little deeper in these reports can help you solving some common problems.



The Diagnostic Reports location

You can access the reports generated by the iPhone following this way:
Settings > General > About > Diagnostics & Usage > Diagnostics & Usage Data

[Update] iOS 8 users: Settings > Privacy > Diagnostics & Usage


I have the following reports stored on my iPhone at the moment:
1. awdd_(date and time stamp)_*
2. LatestCrash-SpringBoard.plist
3. LatestCrash.plist
4. LowMemory-(date and time stamp)
5. SpringBoard_(date and time stamp)

Let’s take a look to see if we can get useful information out of it.

1. awdd_(date and time stamp)_*

In four awdd_* files I’ve seen information that gives us clues about specific errors/bugs, note that I’ve omitted parts of the reports. Many users have disabled the option of sending information to Apple, so you can save battery because radio-transmitters don’t turn-on so often. Anyway, the reports will be stored on the iPhone, and you can have hundreds of them. On the contrary, if you don’t send these reports, Apple doesn’t have this information to further improve the mobile Operating System.

wifiAssociation {} -- error: 4294967196
bluetoothPowerState{}—state is false
wifiMetricIPv4DHCPLetency{} -- 2329 ms
metricsCCBasebandReset{}—mode reset: USB Fatal error

2. LatestCrash-SpringBoard.plist

This report is extensive. It contains 40,478 characters including spaces; this amount would be a third of the RAM of the first Macintosh. In these files all BSD threads are recorded that were active at the time of failure and the thread that failed. At the end of the file, the binary images that were loaded into memory, are added.

In my registry file, the thread 0 failed, generating this information:

Thread 0 name: Dispatch queue: com.apple.main-thread
Thread 0 Crashed:
0 libobjc.A.dylib 0x3188dfbc 0x3188a000 + 16316
1 SpringBoard 0x00270e0a 0xe2000 + 1633802
2 CoreFoundation 0x37d0742e 0x37cf4000 + 78894
3 UIKit 0x351809e4 0x35162000 + 125412
4 UIKit 0x351809a0 0x35162000 + 125344

<..deleted…>

This exception type, Exception Type: EXC_BAD_ACCESS (SIGSEGV), is usually generated by an illegal memory access, caused by uninitialized object pointers. It’s a programming failure, not a hardware defect.

3. LatestCrash.plist

This file contains exactly the same information as the one before. I wonder if it’s wise to generate twice the same report of such a significant file size. Sending these large files to Apple, consumes energy, thereby lowering the battery life.

4. LowMemory-(date and time stamp)

This is an interesting file, low memory warning records. I’ve noticed that having 512 MB RAM on my iPhone 4S isn’t enough most of the times. The iPhone 4 has the same RAM, while the iPhone 3GS has only 256 MB and the first models of the iPhone 128 MB. The process of paging is disabled in iOS. This is a management process that divides memory into smaller programs or pages and writes them to disk (SSD) under pressure. When the iPhone’s RAM is fully occupied, the iPhone OS can’t do much to fix it. The pagination is off to prolong SSD memory life, rewriting continuously shortens lifespan. The read-only pages (mmap) can however be sent to the Solid State Drive.

iOS applications free memory using a technique called ‘reference count’, which counts how many times a particular resource is being referred. When the resource count is zero, the resource is evicted, leaving its memory on the heap (tree data structure type with information belonging to an array).

When the number of unused pages in memory falls below a certain threshold (lowerreport Free pages: 741), the system ‘dislodges’ read-only pages (as I mentioned earlier, they can be moved to the hard drive). If this process doesn’t release the amount of memory required, a low memory warning is sent
to all the active applications. It’s expected that each of these active applications releases memory which they aren’t using; the Purgeable pages: 2356 of the report below, probably relates to this. Images are also deleted from the RAM cache.

Content of the report;

Incident Identifier: A3744153-02C5-422B-8C7E-9937E8280DE9
CrashReporter Key: 2a3ac077512f4b883e67b5cdb67606d0472f0f3a
Hardware Model: iPhone4,1
OS Version: iPhone OS 5.0.1 (9A405)
Kernel Version: Darwin Kernel Version 11.0.0: Tue Nov 1 20:34:16 PDT 2011;
root:xnu-1878.4.46~1/RELEASE_ARM_S5L8940X
Date: 2011-12-20 14:38:42 +0100
Time since snapshot: 39 ms

Free pages: 741
Wired pages: 19832
Purgeable pages: 2356
Largest process: Flipboard

Processes Name UUID Count resident pages
Flipboard

<9d429b121d76360aa6477bd284c5145f>

18854 (active)
Sygic Aura 4987
MyXboxLIVE

<0d1ac81623d537ca9ebfd4cde3f77e50>

2318
Wallpapers 2124
rad.io

<5ec0866e37e6387e9f05cc9a64cbb31c>

1933
NAVIGON

<7f122c5e8abb3687a961f03c17fca4c7>

17504
eBay

<4a4e79fbd7d6397d89d32382a053cca7>

2348
TV Overal

<940c640cf8413e1d81bb90f1463d96d8>

5030 (jettisoned)
hln 16681

<..deleted…>

Assuming that the memory size of a page is 4096 bytes or 4 KB, the header is in a readable format:

Free pages: 741 ( 741 * 4 KB = 2964 KB or 2.89 MB )
Wired pages: 19832 ( 19832 * 4 KB = 79328 KB or 77.46 MB )
Purgeable pages: 2356 ( 2356 * 4 KB = 9424 KB or 9.20 MB )

Flipboard 18854 (73.64 MB)
Sygic Aura 4987 (19.48 MB)
MyXboxLIVE 2318 (9.05 MB)
Wallpapers 2124 (8.36 MB)
rad.io 1933 (7.55 MB)
NAVIGON 17504 (68.37 MB)
eBay 2348 (9.17 MB)
TV Overal 5030 (19.64 MB)
hln 16681 (65.16 MB)

Note: Wired pages are resident system processes and cannot be released.

To improve the iPhone’s usage, it would be better to close some applications from the multitasking bar (double click when the iPhone is unlocked and
press/hold the icon until a red ‘-’ symbol shows up to close the application). The first application I used this morning was HLN newspaper, which occupies 65 MB of RAM in my iPhone, even when it’s closed. I continue the day using Navigon or Flipboard, consuming another 140 MB of RAM.

CONCLUSION

Open most of the applications that you typically use and wait until low memory files are being genrated. Now you can see which applications consume most memory (> 10,000 pages). Close these applications, after each use from the multitasking bar, to keep the RAM memory consumption of the iPhone low.

If anyone has more information or a correction on this issue, don’t hesitate to write a comment.


References;

vafer.org
iphone2010.crowdvine.com


Your opinion counts!

comments powered by Disqus