Hi folks. While tuning my apps loop I keep getting a shutdown at about 2:48 into the game. No slowdown or glitch. It just shuts down with this warning.
“Program received signal: “0”.
Data Formatters temporarily unavailable, will re-try after a ‘continue’. (Unknown error loading shared library “/Developer/usr/lib/libXcodeDebuggerSupport.dylib”)”
I am using the CoreAnimation Instrument to track framerate. Should this be occurring…Probably not but I mean is this a bug in Instruments using the Xcode debugger lib or is it something I can fix? If so how… I was wondering if it had to do with garbage collection but whether I destroy and instantiate alot of game objects or few i get this shutdown. There is nothing special happening at that time in the game. It is a simple track with a physics object sliding down it with a few house meshes left and right along the way, some pickups and a few mesh switchups and that is about it. Nothing ain’t been done a thousand time prior.
Is this fatal? I can’t seem to track anything that is causing it. Nothing in the console except that message and attempts to “continue” leaves an idling Xcode app that has to be force quit. Anybody run into similar? This was a build on the iPad. Unity 3.20f3.
Hi Andee. Yes…I have and there is no anomaly. I am back on the end of this trying to get it to the app store by midnight. I am going to run it through levels when not hooked up via USB to Xcode and see if it is their debugger library that has the unknown error. I will report back one way or another.
Well. I played it without USB cabling and same deal. So I opened the Leaks Instrument and ran it and found my MB usage climbing. It starts at about 38MB total and climbs to 68.40 or thereabout and then shuts down. I assume this is the situation I have read about prior with garbage collection. I guess I am off to find out how to implement GC in this app. I also see a blue line in the Leaks graph showing up at the beginning, stays the same for about a minute ad some and then grows a bit taller. Where do you track down what is leaking? I can’t find a danged faucet valve anywhere to tighten down…heh…
Anybody got any hints, pointers or other ways to beat the climbing MB scenario?
There is particles, but whether they fire/get instantiated or not the MB’s pile up in the Leaks Instrument. I was just looking at another thread and noted that each string concatenation adds to the app. I am using EZGUI which will not accept an int in the timer or scoring fields so I have use ToString(). This is the only thing currently I see piling up…i.e the GUI strings get updated each frame, at least the timer does. I am going to try a GC call.
if (Time.frameCount % 30 == 0)
{
System.GC.Collect();
}
Well…The GC collection doesn’t work. I noticed in the Allocations Instruments window that the MB usage of All Allocations overall bytes just keeps going up and up at the clip of about 20-200k a second. The number of live bytes equals the total bytes so that means it isn’t cleaning anything up??
For example the last test run gave me this before closing down.
All Allocations - Live Bytes 73.51MB #Living 74356 Overall Bytes 73.51MB
Next highest is
Malloc 16 Bytes - Live Bytes 426.95KB #Living 27325 Overall Bytes 426.95KB
The rest are less and watching the graphs form and the numbers in the Statistics window change the only number that keeps going up is the All Allocations. Everything else remains the same. Although it appears that the #Living for Malloc 16 Bytes is pretty big too though it did not keep climbing in the Live Bytes like the All Allocations did.
If I can beat this one item I have the game sussed and on its way out the door. What are the next steps I should take?
The virtual memory system in iOS does not use a backing store and instead relies on the cooperation of applications to release memory. When the number of free pages dips below the computed threshold, the system releases unmodified pages whenever possible but may also send the currently running application a low-memory notification. If your application receives this notification, heed the warning. Upon receiving it, your application must free up as much memory as possible by releasing objects that it does not need or clearing out memory caches that it can recreate later.
UIKit provides several ways to receive low-memory notifications, including the following:
Implement the applicationDidReceiveMemoryWarning: method of your application delegate.
Override the didReceiveMemoryWarning method in your custom UIViewController subclass.
Register to receive the UIApplicationDidReceiveMemoryWarningNotification notification.
Upon receiving any of these notifications, your handler method should respond by immediately freeing up any unneeded memory. View controllers automatically purge any views that are currently offscreen, but you should also override the didReceiveMemoryWarning method and use it to release objects retained by outlets or other data objects managed by your view controller.
If your custom objects have known purgeable resources, you can have those objects register for the UIApplicationDidReceiveMemoryWarningNotification notification and release their purgeable resources directly. Registering for the UIApplicationDidReceiveMemoryWarningNotification notification is appropriate if you have a few objects that manage most of your purgeable resources and it is appropriate to purge all of those resources. If you have many purgeable objects or want to coordinate the release of only a subset of those objects, however, you might want to use your application delegate to release the desired objects."
So…it seems that many of the crashes and other issues with shutdowns due to climbing memory can be stopped when the warning is first received. OK. I want to purge the memory and see if that kills the climbing memory problem, but am not sure where to implement it. Since it is Obj-C code it will not be in Unity scripts. Can someone pipe up here and maybe we can solve this issue running through about five current threads. Unity tech? Dreamora? Prime31?
The handling is already there in the AppController but has no callback representative within the unity engine yet (unlike the app resign active / will become active which map to OnApplicationPause(bool pause) ). What you need to do is make a callback or let it feed the NSUserDefaults with the warning as it happens (NSUserDefaults feeds into PlayerPrefs on the unity side)
OK. I thought PlayerPrefs were called only at the time they were called by some user interaction triggering code with that in. You say “NSUserDefaults feeds into PlayerPrefs on the unity side”. How do I get the applicationDidRecieveMemoryWarning to the Unity side to be handled?
Conversely, you state that the AppController handles it on the Xcode side. Is there a line or two of code in there I and the other can place to “tidy up the joint” when we get memory warnings?
Obviously if the joint is a wreck to begin with cleaning up won’t solve it but I can run these games for hours on the Profiler and in the Editor and on a web build with no climbing memory issue. No null references and no errors or warnings. Just the iPad so far piling up memory for no good reason. The instruments seem to show a leaked block at the very beginning with a light red block and then each frame a blue block seems to indicate it is ongoing but does not seem to have anything directly to do with Unity processes. The window declares four blocks of 16 bytes that appear to be the offending culprits. I am currently downloading Xcode 4.2 and updating the iPad to its latest version. Not that that solves it.
I am thinking a line or two to clean up unused blocks somewhere in AppController.mm upon the “applicationDidRecieveMemoryWarning” being received might do the trick but what that line or two is without getting totally confused testing this and that if something unexpected occurs is the name of this ballgame.