memory crash when i try to stopAnimating UIActivityIndicatorView - iphone

When ever i am trying to update the UIActivityIndicatorView from thread . the app is getting crashed by throwing an exception
modifying layer that is being finalized - 0x7e177fd0
-[CALayer removeAnimationForKey:]: message sent to deallocated instance 0x7e177fd0 .
when i try track the memory leaks form the mallocDebugger tool .
this crash is not happening at all the time happening 1 out of 10
please help me out rom this memory issue
NSAutoreleasePool *pool = [[NSAutoreleasePool alloc]init];
[autoRechargeCell addSubview:activityIndicator];
[self.activityIndicator startAnimating];
if( [PennyTalkAPI getBalanceInfoForAccount:appDelegate.accountNumber withPIN:appDelegate.pinNumber])
{
[autoRechargeCell.switchField setOn:[[NSUserDefaults standardUserDefaults] boolForKey:#"AutoRecharge"]];
[self.activityIndicator stopAnimating]; <<<<<<<<<<<<<<<<<<<<<<
}
else
{
[self.activityIndicator stopAnimating];
}
[pool release];
This is the code i have written

Without looking at code and seeing error I assume you release your Activity Indicator and then you are trying to access it to animate..
Solution: Declare UIActivityIndicator object in .h file synthesize and release it in -(void)dealloc method.

This is either a double release error, or a dangling pointer. You should enable zombie detection in your Scheme's configuration, and try the Zombies instrument in Instruments.

Related

Application Crash due to Memory issue / MBProgressHUD Indicator

I have a strange issue .
I am currently working on a mail app and it used to crash randomly without and error or logs in my console . I checked my Crash Log it showed me Low Memory warning with jettisoned written next to my App.
So I suspect it's an memory issue and went back to trace my memory usage of my application.
I used allocation instrument to detect the overall usage and my application crashed when it's heap size was just 4.59 MB.
Instruments point towards a function where I am using MBProgressHUD indicator.
The culprit is this one line :
[appDelegate showHUDActivityIndicatorOnView:self.parentViewController.view whileExecuting:#selector(refreshInBackground) onTarget:self withObject:nil withText:#"Loading"];
If I replace this with
[self refreshInBackground] everything works fine no issues ..
Here is the code :
-(void) showHUDActivityIndicatorOnView:(UIView*)view whileExecuting:(SEL)method
onTarget:(id)target withObject:(id)object withText:(NSString*)label{
self.HUD = [[MBProgressHUD alloc] initWithView:view] ;
self.navigationController.navigationItem.hidesBackButton = YES;
[view addSubview:self.HUD];
self.HUD.delegate = nil;
self.HUD.labelText = label;
[self.HUD showWhileExecuting:method onTarget:target withObject:object animated:YES];
}
self.HUD is a property which is being retained.
With a slight modification is showWhileExecuting method as follows :
- (void)showWhileExecuting:(SEL)method onTarget:(id)target withObject:(id)object animated:(BOOL)animated {
MyAppdelegate *appDelegate = (MyAppdelegate *)[UIApplication sharedApplication].delegate;
if(!appDelegate.isRequestActive)
{
methodForExecution = method;
targetForExecution = [target retain];
objectForExecution = [object retain];
// Launch execution in new thread
taskInProgress = YES;
[NSThread detachNewThreadSelector:#selector(launchExecution) toTarget:self withObject:nil];
// Show HUD view
[self show:animated];
}
else {
[self done];
}
}
currently I have removed this from my app and it works fine now and it does not crashes even with the usage of 20 - 30 MB heap Memory .
I am not looking for an specific answer or solution here . What I am looking for ways to debug / techniques to debug the issue so that I can get to know what caused my app to crash .
Is it memory overflow . If that's the case then how can I use 20-30 MB right now.
If it's not an memory issue why does my crash reporter shows jettisoned next to my App name .
the culprit line ([appDelegate showHUDActivityIndicatorOnView:self.parentViewController.view whileExecuting:#selector(refreshInBackground) onTarget:self withObject:nil withText:#"Loading"])
Every time when I call this function some memory increases , because of some elements being cached . But when memory reached 4.5 MB ...this line cause it to crash
How do I get to the root cause of this issue . How do I figure out why iOS is killing my app the reason for jettisoned written next to my app
Any help or suggestions would be really appreciated .
Ok. The problem is I was adding the HUD progress bar on my view using
[view addSubview:self.HUD];
I forgot to remove it from the super view in its delegate method:
- (void)hudWasHidden:(MBProgressHUD *)hud
{
// Remove HUD from screen when the HUD was hidded
[HUD removeFromSuperview]; // app crashes at 4.59 MB if you comment this
[HUD release];
HUD = nil;
}
Because of this several views were added every time on one UIView ... I guess there is an upper limit for the number of child subviews on top of each UIView .... apple should mention this in their documentation ...
If you're not using ARC, you have for sure a leak every time you assign the property:
self.HUD = [[MBProgressHUD alloc] initWithView:view] ;
Change your code in this way:
MBProgressHUD *progressHUD = [[MBProgressHUD alloc] initWithView:view] ;
self.HUD = progressHUD;
[progressHUD release];

Memory management with NSThread

I have an app that needs to signal continuously a word in morse code. I did this by creating an NSThread and running some code inside the selector with a "while loop". Here is the code:
#implementation MorseCode
-(void)startContinuousMorseBroadcast:(NSString *)words{
if (!(threadIsOn)) {
threadIsOn = YES; s
myThread = [[NSThread alloc] initWithTarget:self selector:#selector(threadSelector:) object:words];
[myThread start];
}
if (morseIsOn) {
morseIsOn = NO;
}
else{
morseIsOn = YES;
}
}
-(void)threadSelector:(NSString *)words{
NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];
while (![myThread isCancelled]) {
// ///it Does some code here
} //end While
NSLog(#"Cleaning the pool");
[pool drain];
}
#end
When exiting the application (the user presses the button), in the applicationDidEnterBackground the following selector is executed:
-(void)cleanUpMorseObject{ //this is defined in the MorseCode class, same as threadSelector
if (threadIsOn) {
NSLog(#"cleanUpMorseObject, threadIsOn");
threadIsOn = NO;
morseIsOn = NO;
[myThread cancel];
[myThread release];
}
}
The application responds correctly to the event, I’ve checked with nslog.
And then [MorseCode release] is called.
The code looks like this:
-(void)applicationDidEnterBackground{ //this happens in the ViewController
[theMorse cleanUpMorseObject]; //theMorse is an instance of MorseCode
[theMorse release];
}
The problem: Although I call [myThread release] and then [theMorse release] the retainCount of the theMorse is still above 0 (It doesn’t call the dealloc).
The Leaks Instrument doesn’t say I have a leak, but if I open and close the application for like 10 times eventually the Iphone resets. Also in the debugger eventually I see the “Received memory warning. Level=2”.
Also I never see the NSLog before the pool drain…
The app doesn't run in the background.
Any ideas? Thank you
You really should schedule the sending of the message on the RunLoop, the probably easiest way being to schedule a timer (repeat infinitely, and short repeat period like FLT_EPSILON or similar) instead of using threads for that.
Working with threads is complicated and as everyone should avoid it (as Apple stated in its Concurrency Programming Guide, and as most documentation said, "Threads are evil" ;)).
That's because multithreading is a vast and complicated subject, that needs synchronizations, resources protection, being aware of dead locks, critical sections & so on, good and adapted memory mgmt, and much much more. In general if you need to do stuff in the background:
Use mechanisms already in place (like asynchronous implementation of some operations and being signalled by delegate methods or notifications) if available
Use methods like performInBackground:
Use NSOperationQueues
Use GCD
And only in last resort and if there are no other options (or for really specific cases), use NSThread.
This will avoid you a lot of issues as all the other, higher APIs will take care of a lot of things for you.
Moreover, using threads for this task like you do is likely to use much more CPU (will probably reach 100% usage quickly) as there won't be any time left for the task scheduler (that also why even GCD that takes care of all stuff like that is way better than NSThreads, and scheduling the sending in the RunLoop is even better for the CPU if you don't need strong RT constraints)
First, retainCount can never return 0. It is a useless method. Don't call it.
Secondly, leaks only detects objects that are no longer referenced. If a thread is still running, it isn't leaked.
Finally, a thread doesn't stop when you call cancel. It just sets a flag that you have to check via isCancelled to see if it is time to stop work in the thread. Are you doing that?
OK -- easy stuff answered. Next? Try build and analyze. Then use the Allocations instrument and turn on reference count tracking. Then see what is calling retain an extra time.
I decided to give up the NSThread class and used another aproach:
-(void)playSOSMorse{
if ([myTimer isValid]) {
[myTimer invalidate];
[myTimer release];
myTimer = nil;
}
myTimer = [[NSTimer scheduledTimerWithTimeInterval:0.001
target:self
selector:#selector(tymerSelector)
userInfo:nil
repeats:NO] retain];
//the timer calls a selector that performs a selector in background
}
-(void)tymerSelector{
[self performSelectorInBackground:#selector(threadSelector2) withObject:nil];
}
-(void)threadSelector2 {
NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];
//some code here
[pool drain];
//calls another selector on the main thread to see if it needs to fire the timer again and restart the cycle
[self performSelectorOnMainThread:#selector(selectorOnMainThread) withObject:nil waitUntilDone:NO];
}
-(void)selectorOnMainThread{
[myTimer invalidate];
[myTimer release];
myTimer = nil;
if (morseIsOn) { //this is a boolean that if it is true (YES) calls the timer again
[self playSOSMorse];
}
}
I hope this helps somebody :)
Thank you

Crashing App when try to add images..?

I am new iPhone Developer. I am upgrading existing iPhone App. I am using Core Data Model to save data.
In App, there is a 15 square boxes to add images. I am calling a Detached Thread to make a separate process. In this process, I am saving image into two size. I have added observer with image object and remove observer at last.
I am using this method to add Observer:-
[projectImage addObserver:self forKeyPath:#"fileName" options:NSKeyValueObservingOptionNew context:nil];
And this method for making separate Thread:-
[NSThread detachNewThreadSelector:#selector(addImage:) toTarget:self withObject:[dic retain]];
here AddImage is Method like:-
- (void) addImage:(NSDictionary *) dic {
NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];
UIImage *image = [dic objectForKey:#"image"];
projectImage = nil;
projectImage = [dic objectForKey:#"managedObject"];
[projectImage importImageData:image];
[projectImage removeObserver:self forKeyPath:#"fileName"];
[pool drain];
}
And dic is Dictionary
My problem is :
It is Crashing after taking 4-5 images by Camera or Phone library.
If any can guide me to get rid to this problem.
Thanks in Advance
You are leaking memory, and probably because of this your app will crash. I think the app runs out of memory and gets killed.
remove the [dic retain] from
[NSThread detachNewThreadSelector:#selector(addImage:) toTarget:self withObject:[dic retain]];
the object is retained by the method call. See the discussion of detachNewThreadSelector:toTarget:withObject:.
The objects aTarget and anArgument are retained during the execution of the detached thread, then released. The detached thread is exited (using the exit class method) as soon as aTarget has completed executing the aSelector method.
your call should be
[NSThread detachNewThreadSelector:#selector(addImage:) toTarget:self withObject:dic];

Crash - "Collection <CALayerArray: 0x645dfc0> was mutated while being enumerated."

Goal is to "launch a spinner graphic at start of viewWillAppear that loads data before showing the tableview" so the user doesn't wonder why there's a delay before seeing the table. I.e. a UIActivityIndicatorView has been added to the window, and I just want to set the alpha to hide/show it.
I get this strange error when starting a thread to make sure the "spinning gears" imageview (tag=333) gets shown, before moving on to load/calculate stuff in viewWillAppear.
I don't get it on every call to [appdel addGearz] and [appdel removeGearz], it happens for both these, and it's random. It can happen after 2 viewWillAppears, or after 15. If I comment out the line that sets the alpha, everything works.
A typical viewWillAppear looks something like this,
[super viewWillappear];
self.title=#"Products listing"; //and other simple things
[appdel addGearz];
[self getProducts];
[self getThumbnails];
[myTableView reloadData]; //in case view already loaded and coming back from subview and data changed
And here is the code that crashes if the lines with .alpha are not commented out
-(void)addGearz {
[NSThread detachNewThreadSelector:#selector(gearzOn) toTarget:self withObject:nil];
}
-(void)removeGearz {
[NSThread detachNewThreadSelector:#selector(gearzOff) toTarget:self withObject:nil];
}
- (void)gearzOn {
NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];
[window viewWithTag:333].alpha=1.0;
//
// [[window viewWithTag:333] setNeedsDisplay];
[pool drain];
}
- (void) gearzOff {
NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];
[window viewWithTag:333].alpha=0.0;
//
// [[window viewWithTag:333] setNeedsDisplay];
[pool drain];
}
I've used someone else's code, so... anything obvious you can see? Surely I must be able to change alpha of UIViews in a thread? Do I need to "embed" the alpha-change in some "stop enumerating while I change this"-code?
I made it not crash by moving that alpha-change-line to above the pool alloc or below the [pool drain], but then I get a lot of "autoreleased with no pool in place - just leaking"-messages.
Apparently, there's something I don't understand about this thread code.
You must not try to modify the UI on a separate thread. UI should only be manipulated on the main thread.
Instead of detaching a new thread, you should use performSelectorOnMainThread:withObject:waitUntilDone:. This will ensure that the method will be called on the proper thread.

Threading works in simulator but not on iPhone

I'm trying to display a UIActivityIndicatorView while background processing takes place.
The below simplified code works when I try it in the simulator(the alert is displayed)..but when I download it to my phone from Xcode, the background thread does not seem to get called at all. (the alert never gets displayed)
Any ideas?
-(void)viewDidLoad {
[self performSelectorInBackground:#selector(runInAnotherThread) withObject:nil];
}
-(void) runInAnotherThread {
NSAutoreleasePool *pool = [ [ NSAutoreleasePool alloc ] init ];
int i;
for(i=0;i < 1000 ;i ++){
NSLog(#"INDEX = %d", i);
}
[self performSelectorOnMainThread : # selector(backToMainThread ) withObject:nil waitUntilDone:NO];
[ pool release ];
}
-(void) backToMainThread {
UIAlertView *completeAlert = [[UIAlertView alloc]
initWithTitle:#"Back to main "
message: #"Success"
delegate:nil
cancelButtonTitle:#"OK"
otherButtonTitles:nil];
[completeAlert show];
[completeAlert release];
}
Have you you tried cleaning your build? I just ran your code on my device and simulator and it works as expected in both cases
Use NSOperation instead of raw thread manipulation. It abstracts all sorts of stuff for you (priority, autoreleasepools etc...). ? You can simply add some kind of delegate to your NSOperation subclass to get a callback when you need.
Thanks for replying so quickly!
It turned out that the issue was not in this code fragment at all. I was executing this code dependent on a value in the keychain. While my simulator's keychain has that value, my test iphone did not have this value.
Feel so silly for troubling all of you. But following up on the reply from nduplessis helped me narrow down the issue.