4

Sorry for the long post...I'm have a habit of being pretty verbose. :-P

I have an odd problem with my iOS app that has been reported by users for several months now. I've looked into it a few times, but keep hitting a roadblock with it. The app is jettisoned, but does not appear to be using very much memory at the time it is jettisoned. E.g., here's one log from a user (app name and identifiers changed):

Incident Identifier: OMIT
CrashReporter Key:   OMIT
Hardware Model:      iPhone2,1
OS Version:          iPhone OS 4.3.5 (8L1)
Kernel Version:      Darwin Kernel Version 11.0.0: Sat Jul  9 00:54:20 PDT 2011; root:xnu-1735.47~1/RELEASE_ARM_S5L8920X
Date:                2011-10-01 09:50:03 +0100
Time since snapshot: 41 ms

Free pages:        710
Wired pages:       10076
Purgeable pages:   416
Largest process:   SpringBoard

Processes
         Name                 UUID                    Count resident pages
          MY_APP <f01c118296fe329899981e37e00c6cc3>    2258 (jettisoned) (active)
MobileMusicPlaye <c26fcc882cf130f09979f9ca08521fce>    1024 (jettisoned)
     MobilePhone <d3042adf269630daa58e43d0ba5eeb54>     649 (jettisoned)
      MobileMail <573ff3a3e09334c7aa51d8568c845e11>     716 (jettisoned)
             lsd <3fafa485b73836acb973d50feabd963a>     148
         notifyd <9966082842de313a8e05a001c783faf4>     117
        BTServer <01550e9527353eecae41ebee0f889603>     182
      CommCenter <7d9446365b4836968ae361626ef8f939>     440
     SpringBoard <5c55c6fba0843b0e924e116413b8c9d4>    3305 (active)
      accessoryd <d30e340e36df356bbde3347a6ed1ef87>     160 (jettisoned)
            apsd <47ffc9ce9f84371588bd3f937aaa20bb>     278
         configd <a6d457fca42732d9ba809d03a2b3e3ae>     427
   fairplayd.N88 <46c1d3fbe93a370089f783f96a5cf531>     177
       locationd <9088e845dcbe37d890c8758655bf34c6>    1065
   mDNSResponder <caf94711b8093dc5bc5736306f8ae818>     200
    mediaremoted <21af791e80823c9f90f0be2b77a3d885>     251
    mediaserverd <c731263114c33a07aef7bccdcf667271>    1512
       lockdownd <1c7f2b41744c35dc92f679e90a73e240>     278
         syslogd <d81669e7bdb93f9b9012020beac826f4>      99
usbethernetshari <25130d2f9a0334e3ae28780250343144>     110
         launchd <e2d41e07a0743a089eadbae765709c82>      88

**End**

This is from a 3GS device and from what I've seen of LowMemory logs there's not much running there (13484 pages...about 55MB?). Our app is the second biggest, but at 9.3MB resident is hardly huge. It also consistently happens after about 15 minutes of use for the affected users (but, the affected users list is pretty small).

As evident in the log, the app was active (the phone was top locked) as is always the case when reported. We do receive low memory warnings prior to being jettisoned and properly implement viewDidUnload and didReceiveMemoryWarning in all views. It does appear to be freeing memory too as 9.3MB is smaller than the normal footprint of about 12MB. And, the app doesn't update any views while top-locked per Apple's guidelines (and because it's just a good idea. :-P). We don't keep a whole lot of stuff in memory...most sits in a DB and grabbed only when needed then freed. We probably use more memory for UI images than anything (which should be released in viewDidUnload for loaded views).

From extensive memory testing with leaks and checking memory usage with VM stats and allocations, I'm pretty confident there are no memory leaks nor excessively high memory spikes or usage (at least on the 3G and 3GS devices I've tested on). Nor does the dirty memory size appear to be excessively high (usually around 11 MB while tracking and 12 MB resident total). The low memory log reflects this. And, because I'm paranoid, I've even had users run with memory logging inspired by this discussion: iPhone app uses 150 MB memory and still no low memory warning!. The logging seems to corroborate the low memory usage (app resident mem was reported as 9,773,056 bytes just before the above jettison). The virtual size IS big (342,740,992), but...it's virtual. :-P

This only affects a small subset of users and I've only ever seen it reported on 3GS devices (iOS 4.x...version varies, but seems to have started with 4.2 I think). And, it consistently happens after about 15 minutes for the affected users.

I have tried having the user use the app with simplest use case after it's reported in case there is some odd behavior that causes the problem, but it still occurs. Which leads me to believe it's some problem with the users' phones, but I don't like telling them that without something to point to that could be the issue. I can't reproduce it on my 3GS or 3G test devices.

It doesn't seem to be any of the usual culprits (high dirty memory usage, memory leaks, etc) so I'm pretty much stumped on how to address this one. Any suggestions? Or at least a path I can take to try to investigate further? :-P

Community
  • 1
  • 1
stuckj
  • 977
  • 1
  • 13
  • 24
  • Another note. I use host_statistics (I know it's not representative of device available memory) in the memory logging as well and observe the total memory decreasing after each memory warning when this problem is observed. The inactive memory slowly decreases towards 0 and that's when the app is jettisoned. Could this suggest user space decreasing for some reason (memmap?)? I assumed it was always fixed. Or, is host_statistics just completely unreliable on iOS? Or, maybe iOS limiting memory after warnings? Just speculating... :-P – stuckj Oct 07 '11 at 21:04
  • UPDATE: I can now re-produce this with my test device. I re-compiled developer signed, but with the release optimizations enabled (duh...should've tried that earlier). But, I can't reproduce it every execution and, worse yet, I can't reproduce it AT ALL when connected to the debugger or instruments. Ug. I'd suspect a race condition somehow causing a memory leak, but all the measurements outside instruments (including the LowMemory log) suggest low memory usage. If I could reproduce it with instruments I could verify it for sure... :-P So, why would it be jettisoned??? – stuckj Nov 02 '11 at 18:13
  • Were you able to find a resolution or make any progress yet? We are seeing a very similar issue with the 3GS and our customers - not happening all the time but we can reproduce it in-house. The app is getting jettisoned the same way - No leaks reported either - we have been trying to track it down but no luck as of yet. It is pretty annoying indeed. –  Dec 15 '11 at 23:16
  • Nothing definitive yet, but I recently updated to compiling against iOS 5 which required switching to LLVM (since the latest xcode dumps gcc on the front end at least). I changed over to pure LLVM 3 (same optimization options) and have noticed that it has not been jettisoned on my test device since then. We just deployed an update so waiting to see if we there is a reduction in reports. – stuckj Dec 17 '11 at 02:13
  • After several weeks of testing we have not had reports of nor been able to replicate the crash after switching to LLVM 3. We did have some code changes with that upgrade so it's possible I inadvertently fixed a problem, but they were pretty benign so I'm chalking this up to a bug with optimizations in GCC on iOS (although I can't make it more specific than that. :-P). – stuckj Jan 04 '12 at 15:56

2 Answers2

2

After switching to using LLVM3 (since vanilla gcc isn't supported on iOS 5), this problem seems to have gone away. There were minor code changes with the update as well and LLVM3's static analyzer did also find a couple small memory leaks that were not detected by gcc nor by leaks so I cannot say definitively that the problem was gcc (on iOS) specific. But, switching to LLVM 3 seemed to solve the problem whether directly or indirectly through better static analysis. :-P

Hope this helps someone else.

stuckj
  • 977
  • 1
  • 13
  • 24
0

Long shot, what kind of optimizations are you using ? Something that affects math precision could make a difference, say a fast-math or something. This could affect memory if say you had a float somewhere in malloc mem cal.

Like I said long shot...

led42
  • 781
  • 5
  • 10
  • I'm just using -Os with no special addition or removal of flags. Looks like -ffast-math is only turned on with -Ofast. Thanks for the input though. Was starting to wonder if anyone would answer. :-P – stuckj Nov 14 '11 at 22:25
  • No prob, seems a stumper, looks like if have a leak somewhere and are not able to release memory fast enough, maybe an object of yours is being kept inside a system one, so when you release your copy the system one stills kills your app. Have your tried without using the debugger just looking at the console when the problem happens ? Are there also system apps dying (Mail for ex.), you could also try old school debug, a bunch os NSLog on key functions, even dumping a reference pointer can help you figure if an object is being released... – led42 Nov 15 '11 at 10:45
  • Yep, MobileMail got jettisoned with the crash log above, although I'm assuming it was due to the OS thinking there was so little free memory. I did several runs attached to the profiler without the debugger, but haven't tried any with just looking at console output. I'll give that a try in case anything interesting pops out. I do have quite a lot of logging that I have turned on to try narrowing down where the culprit is, but nothing stands out. – stuckj Nov 23 '11 at 19:42
  • Let me know if you got it, it's kicking my OCD not getting the answer :-) – led42 Nov 23 '11 at 21:10
  • I'll definitely be posting back here when / if it's fixed. :) At least it's not happening a whole lot, but is definitely a killer bug for those users that it affects so I definitely want to fix it! – stuckj Nov 28 '11 at 14:57