tags:

views:

213

answers:

4

I have an iPhone app that, for some users, sometimes behaves as if with the main UIView has been removed from the view hierarchy. It always happens coincident with a significant event in the game. Other Core Graphics-drawn UIViews that are above it in the z-order remain, but the main one (an OpenGL view) appears to be gone, leaving the background (a solid color).

The app does not crash (it keeps running, without the view), and this seems to happen very consistently for affected users. Unfortunately I am not able to reproduce it.

I suspect a memory issue -- that would be the easiest explanation -- but based on my reading it looks like didReceiveMemoryWarning only deallocs views that aren't visible, and aside from that the memory usage for my app is pretty small. Also, the "significant event" only results in OpenGL drawing and a SoundEngine call -- no view manipulation.

Anybody out there seen something like this before?

A: 

Yes, infact one of my applications very occasionally exhibits this problem and it does seem to be memory related.

I have had no success tracking it down either by debugging or analyzing the program flow. I have verified that the view in question is destroyed and not just hidden in some way.

It happens so infrequently that I haven't looked into it to deeply, but I do think it's caused by something in the OS in some way,

Andrew Grant
Check out my self-supplied answer below; it may help your app too.
Adam Preble
A: 

As is made clear in the SDK documentation, when your app is running low on memory, views that are not in use can be collected. When it's needed again, it's re-created. This is to conserve precious iPhone resources. Your best bet is to retain the view so it can't be released.

August
If the view in question is visible it's a pretty good bet that it's "in use"
Andrew Grant
August - Thanks for your attempt to help, but please read my question carefully. As Andrew points out the view in question is in use.
Adam Preble
A: 

You can easily test low memory in the simulator to debug this problem if it is memory related.

Roger Nolan
True; unfortunately it does not reproduce the problem (or appear to have any effect on the app).
Adam Preble
All the simulator does is call the low memory methods on your classes. It does not simulate the OS running low on resources.Sadly there's a number of reasons it's called a simulator and not an eumlator.
Andrew Grant
A: 

The problem ended up being an uncaught NSException (from a third party library) thrown in the app's timer thread, which killed the timer thread but not the rest of the app. The good news is that crash reports are generated in this case, which can make tracking it down much easier if you know to look/ask for them.

Adam Preble