7

I'm creating an application which features having multiple animations. There are 50 pages and on each page there is a different animation and each animation uses many images.

I'm using UIPresentModelViewController for presenting the views and am changing images using NSTimer.

When I swipe continuously the application crashes with this message:-

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 searched a lot but couldn't find any proper solutions to this issue.

Nic
  • 12,220
  • 20
  • 77
  • 105
user973012
  • 239
  • 2
  • 7
  • 1
    Have you tried to run "Analyzer" to see if it finds any potential leaks? – 5StringRyan Sep 30 '11 at 15:54
  • @HansGruber : Yes we tried running with memory leaks but we dont have any leaks found. Any other solution on same please.. Thanks.. – P.J Oct 01 '11 at 09:58
  • Analyzer and leaks are different tools. There is a static clang analyzer that you can use to find not only memory leaks but other problem spots in code. It's a good idea to run it periodically. Note that the static clang analyzer does not run under instruments and is not a profiling tool. You will find it under the Products menu. "Products > Analyze". Leaks on the other hand is a profiling tool for monitoring objects to see if they are not released after all references to the object are removed. – Sam Oct 03 '11 at 21:56
  • Post the code where you update images. You may have a leak that is getting out of control. Also, I assume you read [Data Formatters temporarily unavailable, will re-try after a 'continue'](http://stackoverflow.com/questions/3843903/data-formatters-temporarily-unavailable-will-re-try-after-a-continue). The problem there was due to memory leaks. – Sam Oct 03 '11 at 22:00
  • Restating its probably memory leaks of some sort. Are you releasing your timers on the views correctly? Remember that they retain their target, so if you have a timer outstanding not only will it remain and potentially leak, but the target its retaining will as well. Which means every one of those views you load will never go away. – EricLeaf Oct 08 '11 at 15:47
  • Note that you need to use an image loading method that will manage loaded images for you and allow "stale" ones to be "unloaded". `[UIImage imageNamed:...]` is one option. – Hot Licks May 31 '13 at 19:23

8 Answers8

0

If you're using lots of images for a single animation you're doing it wrong. You should have one, or several very large images and then just show a portion of that image. This way you can load very few images, but have the same affect of having many images.

Look into cocos2d or other frameworks that are popular for making games, as they will be much more efficient for animations than just UIKit.

Sean
  • 2,106
  • 2
  • 16
  • 24
0

Find out the reason for memory crash using instrument tool and then refactor the code with best practises with recommended design pattern. There is no unique solution for this. Thanks.

deepax11
  • 199
  • 3
  • 7
0

Just check within your code that you are making some mistake by adding new view every time but forgot to release it...

Nilesh Kikani
  • 2,628
  • 21
  • 37
  • Thanks for your answer, but we have used IBOutlet in XIB and changing images on it accordingly.... Please suggest us something on it more.. Thanks.. – P.J Oct 01 '11 at 09:56
0

You need to look at (and perhaps post) the stack trace when you crash. And the code that changes the image. This sounds like memory bloat (not a true leak in that someone is still referring to memory). The Analyze menu item might catch something (and you should definitely run it), but you may need to run the Allocation instrument and look at heap checks. See http://www.friday.com/bbum/2010/10/17/when-is-a-leak-not-a-leak-using-heapshot-analysis-to-find-undesirable-memory-growth/ for more.

David Dunham
  • 8,139
  • 3
  • 28
  • 41
0

This sounds like a stack overflow to me. In the "Other C Flags" section of the project's C/C++ language settings add a flag for "-fstack-check" and see if that turns up any unwanted recursion.

John Stephen
  • 7,625
  • 2
  • 31
  • 45
0

Signal 0 is usually due to memory low as the app using too much memory. Check whether memory warning method is called or not.

The data formatter thingy failed to load might be due to there's not enough memory to load it..

sicKo
  • 1,241
  • 1
  • 12
  • 35
  • This answer is correct, if you get a signal 0 then you used up all the available app memory. You need to go back and rewrite your code so that it does not hold all the decompressed images in memory at the same time. That is your most likely cause of running out of memory, because decompressed images are HUGE! – MoDJ Jun 20 '13 at 23:06
0

50 views like you describe sounds like a big memory hog. So I suspect memory management is unloading some views. Then when your program needs the views, they are not there and your program crashes. The error message doesn't quite fit this, but it may not be accurately telling you what the problem is.

Consider the following possible scenario, and see if it fits how you coded this program.

In order for the OS to manage memory, it can unload views and reload them as needed. When this is done, the methods viewDidUnload, loadView, and viewDidLoad are called.

viewDidUnload:

This method is called as a counterpart to the viewDidLoad method. It is called during low-memory conditions when the view controller needs to release its view and any objects associated with that view to free up memory. Because view controllers often store references to views and other view-related objects, you should use this method to relinquish ownership in those objects so that the memory for them can be reclaimed. You should do this only for objects that you can easily recreate later, either in your viewDidLoad method or from other parts of your application. You should not use this method to release user data or any other information that cannot be easily recreated.

loadView:

The view controller calls this method when the view property is requested but is currently nil. If you create your views manually, you must override this method and use it to create your views. If you use Interface Builder to create your views and initialize the view controller—that is, you initialize the view using the initWithNibName:bundle: method, set the nibName and nibBundle properties directly, or create both your views and view controller in Interface Builder—then you must not override this method.

Check the UIView Class Reference --

viewDidLoad:

This method is called after the view controller has loaded its associated views into memory. This method is called regardless of whether the views were stored in a nib file or created programmatically in the loadView method. This method is most commonly used to perform additional initialization steps on views that are loaded from nib files.

You may have inadvertently initialized these views in your init methods rather than in your loadView methods. If you did this, then when the OS unloads a view (you will see viewDidUnload is called) the memory associated with the view and all subviews (all of the images and animations) will be unloaded. This saves memory, but when you need one of those unloaded views to reappear, loadView will be called first if the view had been previously unloaded. If your view setup is done in the init methods rather than in loadView, then the view will not be setup again. But if the view setup is done in loadView method, it can be recovered after memory management unloads it.

Jim
  • 5,940
  • 9
  • 44
  • 91
  • viewDidUnload is deprecated in iOS 6.0. Views are no longer purged under low-memory conditions and so this method is never called. – Bastian Jun 07 '13 at 18:49
0

There is one and easy way to find out leaks that is hard to find via leaks instruments and so on - Zombies analyser. It shows every unlinked memory in your program, and you can easily detect leaks and optimize code in minutes.

art-divin
  • 1,635
  • 1
  • 20
  • 28