5

I am trying to wrap my mind around an issue (eluded to in this question). The context is: turn-based game, developed with cocos2d version 2.0, obj-c, no ARC, currently prepping an AppStore update to account for some iOS 7 issues (mine, not iOS7).

My own instrumentation, as well as Instruments, show no leaks, no abandoned memory, nothing... flat. This also used to be the case under iOS 4,5,6.1. However, in my test rundown prior to submission, when profiling on device, i see a 1Mb increase per 2 minutes, with the game sitting idle, ie no user interactions whatsoever (see pic below).

enter image description here

The only thing i can see is this IOAccelResource category running amuck between generation capture.

  1. Would you have any suggestions as to what could that be ?

  2. I cant find much about an IOAccelResource ... can anyone of you point me in the right reading direction ? If this is indeed cocos2d related, i would not mind digging in there, but i dont know where to start looking.

  3. Also, i would like to run with 'as close to release' a build as possible, and still be able to measure the memory footprint over time. Could you suggest me a method for measuring process size ?

    tia.

Community
  • 1
  • 1
YvesLeBorg
  • 9,070
  • 8
  • 35
  • 48
  • I have the same issue with a Cocos2d-x 2.2 game coded in C++ and Objective C++. Cannot figure out where it is coming from :( – Cory Trese Nov 17 '13 at 04:05
  • @CoryTrese see my answer below : running release and monitoring process size from the outside looking, the process size is stable ... same code base, same everything except : no debug, optimized for size and speed. – YvesLeBorg Nov 17 '13 at 04:09
  • I am facing the same issue. the difference is I am using `OpenGL ES`. So, I guess, even if you have removed the relation between `UIAccelerometer` and `Cocos2D` and though you observe the growing allocation graph, it leads me to consider that there is no problem even with `OpenGL` also. Now there is one thing you mentioned in your below comments is `DisplayLink`, which can be the common part for both `Cocos2d` and `OpenGL ES` for rendering graphics to screen. If this is the case, then there is a fault with either iOS or Instrument. – sam18 Feb 01 '14 at 06:43

5 Answers5

2

As far as I can tell , this is a bogus (probable instruments bug). When using a 'release' version of the same code base ... ie no debug ... and monitoring the process size (ie no debug process attached to the running process), the memory creep is not there.

YvesLeBorg
  • 9,070
  • 8
  • 35
  • 48
  • That's not the case for me. I got this problem, I ran on release with no debug process attached to the running process, and the process size was still growing. The weirdest thing is that some of my team members get it, while other don't. I think it's related to OpenGL, are you guys using it? – Ricardo Sanchez-Saez Aug 15 '14 at 19:41
  • Hmm, on further investigation `Enable Zombie Objects` on `Edit Scheme > Run > Diagnostics` caused this. – Ricardo Sanchez-Saez Aug 15 '14 at 19:54
  • That is a new one on me. I verify every day that there is memory creep only (and only) when running with debug. For example, build and run with xcode, creep. Stop process within xCode, and restart the app (same build) on device, no creep. Using GL-2, this is a gaming app built with cocos2d. But i see evidence of the same with a plain vanilla UIsomething app of mine. – YvesLeBorg Aug 15 '14 at 20:54
1

Educated guess: IOAccelResource could be used by UIAccelerometer. It certainly sounds like an accelerometer I/O kind of thing.

Since UIAccelerometer is deprecated in iOS 7 but still used by cocos2d perhaps there's an issue there Apple didn't catch or care about. Just for testing try to remove any UIAccelerometer reference from cocos2d to see if this goes away. Release builds should not affect Instruments memory monitoring, and an archive build is simply a release build from the code perspective.

CodeSmile
  • 64,284
  • 20
  • 132
  • 217
  • hmmmm ... nice ewag ! i'll give it a shake and come back shortly. – YvesLeBorg Oct 07 '13 at 21:01
  • PS: maybe this is somewhat related: http://stackoverflow.com/questions/13231570/is-it-normal-that-my-cocos2d-app-increase-real-memory-usage-every-second At least it seems to be indicating this could be an on/off issue with cocos2d. I certainly saw this behavior before, but not in every app. – CodeSmile Oct 07 '13 at 21:03
  • ok ... i doctored cocos2d to remove any and all references to accelerometer classes (only in CCLayer) ... no difference. Investigating probable other cause right now : Instruments. – YvesLeBorg Oct 07 '13 at 21:56
1

You could try monitoring allocations using heapshot analysis through Instruments. That should give you an indication as to where the additional memory is being allocated. Maybe you've already tried this?

Rob Segal
  • 7,515
  • 12
  • 43
  • 72
  • hmmmm .... i looked for 'heap shot' in mil-std-xcode5 instruments but did not find it (some other thread mentionned that). What instrument is it and how do i 'unveil' that thing please ? – YvesLeBorg Oct 07 '13 at 23:43
  • Yeah they've changed the terminology slightly for XCode5. Heapshot analysis is now called "Generations" and taking heapshots is now "Mark Generation". It's the Allocations instrument that you want. Click on where you see "Statistics" in your screenshot to be able to browse to the Generations page. – Rob Segal Oct 07 '13 at 23:50
  • +1 for the 'xcode' course. fyi : 86.3 % of the creep is IOAccelResource, deep in CS::Display::DisplayLink::dispatch_item. The rest is my own stuff, which is under careful investigation at the moment. Also FYI, if i build with AppCode (the same scheme, same build config), and run instrument via the IDE, i get no creep. If on the other hand, i attach instruments to a running process, i get the creep. – YvesLeBorg Oct 08 '13 at 00:14
  • Sounds like there's some leads to go at least there. I've not used AppCode before so I can't speak to that but certainly some interesting results. On another tangent you could try switching any accelerometer code in Cocos2D to use Core Motion instead. – Rob Segal Oct 08 '13 at 16:23
  • yeahhh ... what a mess of trouble. See on Stefen's answer : i ditched completely the accelerometer from cocos2d and the leak is there. I suspect that IOAccelResource may be related more to GPU (hardware accel.) than accelerometer in this case. That is why i cant find a thing in the literature , ie Apple private stuff. That would be coherent with the fact that the leak (not detected by Leaks by the way) is in DisplayLink. – YvesLeBorg Oct 08 '13 at 17:17
1

The Enable Zombie Objects option on Edit Scheme > Run > Diagnostics can cause this behaviour. Be sure to disable it if you have it enabled.

Ricardo Sanchez-Saez
  • 9,466
  • 8
  • 53
  • 92
1

Ricardo has half the answer : zombies objects is part of this. You need both Zombies enabled AND an attached process to get the creep.

In summary :

  • no zombies, no memory creep.
  • with zombies, no debug process attached, no memory creep.
  • with zombies, debug process attached, memory creep.
YvesLeBorg
  • 9,070
  • 8
  • 35
  • 48
  • I'm pretty sure I have experienced the memory creep on a Release-compiled build with no debug process attached (using [this method](http://stackoverflow.com/questions/7989864/watching-memory-usage-in-ios) for memory reporting). Also, why didn't you edit your previous question instead of adding a new one? – Ricardo Sanchez-Saez Aug 18 '14 at 11:44
  • Probably something different in our contexts : I principally use cocos2d for all UI stuff. I've left an app running for hours yesterday (no Zombies, debug attached) without any creep. To be certain i've doctored cocos2d to report process size with fps throughout, comparing with Instruments (Monitor, does not attach). Really strange this thing. – YvesLeBorg Aug 18 '14 at 11:48