Daemons dying in an out-of-memory loop on iPad Mini Retina
| Originator: | ben | ||
| Number: | rdar://15965950 | Date Originated: | 2/4/2014 |
| Status: | Verify | Resolved: | 7.1b5 (11D5145e) |
| Product: | iOS SDK | Product Version: | iOS 7.0.4 (11B554a) |
| Classification: | Crash/Hang/Data Loss | Reproducible: | I Didn't Try |
I was just using Safari and the fast app switcher when all of a sudden my iPad Mini Retina became unusably slow--taps took 30+ seconds to register. I went ahead and grabbed syslogs, crash logs, and a time profile while this was occurring. From the logs, it appeared that this started happening at about 2/2/14 12:05 PM and stopped at about 2/2/14 12:12 PM, when SpringBoard relaunched itself. The time profile doesn't seem to reveal much other than launchd relaunching wirelessproxd in a loop due to jetsam policies. Once SpringBoard restarted, everything seemed fine again. You can see from the logs that I ran MemoryEater (basically my own version of Apple's internal Memory Muncher) and was able to dirty >600 MB of pages before dying, as expected. One weird thing to note is that the number of rpages for backboardd and SpringBoard is negative in the attached low memory reports. Not sure how that is possible... Steps to Reproduce: I didn't try to repro it. This is the first time something like this happened. Expected Results: Daemons shouldn't go into a crash loop. Actual Results: Daemons went into a crash loop due to memory pressure, causing the device to be unusable. Version: 7.0.4 11B554a Notes: Configuration: Retina iPad Mini (A1489) Attachments: 'ipad-hang-all-crashlogs.zip', 'ipad-hang-syslog.txt' and 'ipad-hang.trace.zip' were successfully uploaded.
Comments
Please note: Reports posted here will not necessarily be seen by Apple. All problems should be submitted at bugreport.apple.com before they are posted here. Please only post information for Radars that you have filed yourself, and please do not include Apple confidential information in your posts. Thank you!