Open Radar

 
Summary:
Our iOS app sends a lot of analytics, and so we use Segment.io to handle the many services. A few of our customers recently started reporting crashes after using the app for a minute or so, and we traced it back to out-of-memory crashes caused by their objects.

After finally hooking up Instruments, we got a trace (attached, hopefully—it's 2.86 GB)…and it looks like it might actually be a bug in `-[NSArray writeToURL:atomically:]`.

----

Roughly what Segment does is:

1. On startup, load any events from disk into an in-memory array.
2. When an event happens, append it to an in-memory array of events, and atomically write those events to disk.
3. Every so often, send a batch of events to the server. When it gets a successful 200 OK, remove them from the in-memory array, and write that smaller array to disk.

We traced the steps to reproduce to the app container, and noticed that the plist of events on out-of-memory crashing phones was consistently HUGE—47+ MB.

We suspect that whatever file manager is trying to coordinate these writes is leaking when receiving a LOT of very large arrays to be written to the same file.

----

The test iPhone had plenty of disk space left (20+ GB).

The segment code is here: https://github.com/segmentio/analytics-ios/blob/f8c25e64ce20c62041088fee7463bf089fd47615/Analytics/Integrations/Segmentio/SEGSegmentioIntegration.m#L402

Steps to Reproduce:
1. Have a 47 MB plist.
2. Load it into memory.
3. Append a row to its top-level array, and write it to disk. A lot. Multiple times a second.

Expected Results:
There shouldn't be 64 MB CFData chunks persisting *minutes* after Segment asks them to be written to disk.

Actual Results:
There are!

Notes:

Configuration:
iPhone 6s (MKT32LL/A)