Library/Preferences folder grows ad infinitum

Originator:sean
Number:rdar://26861863 Date Originated:17-Jun-2016
Status:Open Resolved:3rd party to resolve
Product:iOS Product Version:
Classification: Reproducible:NO
 
Summary:
Our application is deployed to iPads at businesses around the country. The application runs almost constantly. Most of our devices are controlled by our MDM program. Our application is signed with an enterprise distribution certificate.

Since the beginning of June 2016 some merchants have reported "out of space" errors on our in-store iPads. Storage & iCloud Usage in Settings reports that our application has grown to consume all available local storage space. When we collected the iPad we found that the Preferences folder within our app's sandbox was full of duplicate plist files, like "com.mycompany.myapp.plist.3gaPYul". In many cases the preferences had been collecting since the iPad was deployed. The files were created every few hours, with no immediately visible pattern.

After deleting and reinstalling our app the same devices were "fixed". They did not make duplicate preferences.

This StackOverflow question from 2010 describes the same bug: http://stackoverflow.com/questions/4561002/why-is-nsuserdefaults-leaving-temporary-plist-files-in-library-preferences-for-m

Steps to Reproduce:
Unfortunately we've been unable to reproduce.

Expected Results:
Preferences folder should not grow to fill the device's available storage.

Actual Results:
Preferences folder grows to fill the device's available storage.

Version:
9.3

Notes:
Many of the iPads have been creating duplicate preferences since they were deployed last year, some as early as August 2015. The iPads were originally running some version of iOS 8. The preferences continued to grow through the updates to iOS 9 and 9.x.

Configuration:
original iPad Mini, wifi only

Comments

response from Apple

Thanks for your update. We are closing this report. If you see this issue again on a current release, please file a new bug report with fresh diagnostics.

By sean at July 5, 2016, 2:41 p.m. (reply...)

my response to Apple

Based on your advice we've removed the offending 3rd-party framework that was abusing NSUserDefaults and we have not seen the issue return.

The few devices I've been able to bring back and diagnose don't have any crash reports. Based on the console it looks like the iPads were entirely out of storage space and couldn't persist their own crash reports. I'll continue to look for crashlogs for cfprefsd. Thank you!

By sean at July 5, 2016, 2:41 p.m. (reply...)

response from Apple

Could you check whether the devices this occurs on have crashlogs for cfprefsd? A plausible scenario is that the devices in question are under significant memory pressure, and when your app writes significant amounts of data to preferences (we’d suggest storing less, of course! it’s really meant for user settings), it triggers the OS to decide to terminate cfprefsd to reclaim memory, leaving the temporary file from the in-progress save behind.

iOS Crash Log Instructions: https://developer.apple.com/services-account/download?path=/iOS/iOS_Logs/Crash_Log_Instructions__iOS.pdf

By sean at July 1, 2016, 1:03 p.m. (reply...)

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!