I am getting a crash the second time I attempt to add a certain view as a subview. The crash happens here:
-(void)AddAsScrollableSubContext:(UIView*)view {
[pExtendedScrollableSubContextBounds addSubview: view]; //CRASH HERE
pSubScroll.userInteractionEnabled = true;
}
the second time I call...
[mSongContext AddAsScrollableSubContext:pEQRoot];
The flow is something along the lines of
[mSongContext AddAsScrollableSubContext:pEQRoot];
...Load a lot of stuff
...Press a Button
...Unload a lot of stuff
[pEQRoot removeFromSuperview];
...Press a Button
[mSongContext AddAsScrollableSubContext:pEQRoot];
When I get the bad access the callstack looks like the following:
Both objects (pExtendedScrollableSubContextBounds and pEQRoot) appear to be valid. Adding other subview to pExtendedScrollableSubContextBounds works fine and calling other operations on pEQRoot (subview, frame) also work.
I read the in objsend r0 was the object and r1 was the selector so I looked at the memory address for r1 and saw...
This feels like I am trashing memory somewhere around isKindOfClass: but I am not quite sure. Could anyone point me to more info on iOS obj_msgsend? is there a way I can setup a watch point to catch when this memory trash is occurring?
Use NSZombies to fix the problem.
On a slightly unrelated note, there's a rule of thumb - NARC which stands for new, allocate, retain, copy. If a method call includes any of these keywords, then we have ownership of the object and we are then supposed to release the object.
Related
After hours of sitting on this problem (I really feel like a chicken on a dragon egg) I come here to ask.
The problem is: I have an async queue with my timer (created with mach_absolute_time()) which after some time interval gives NSNotification to defaultCenter, which then runs my method. In the run method, there is a method call for finding out intersections of views. I recently switched to ARC as it seemed to be a really good idea. Now I regret it a bit, since pre-ARC, this code did allocate and deallocate correctly, but now it only allocates itself. Maybe I'm missing some code to deallocate it manually, however, when I tried to set the view to nil, it did not help at all. Also, in Allocations, the malloc 4.00 KB keeps raising because of that intersect method, which is really the reason why I ask, since after some time, it reaches a limit, I receive a memory warning and my app crashes.
The reason I need this method is that I iterate through subviews of view with obstacles. And when distance of another view from some of the subviews reaches limit, I run some code.
So now for some code:
This is the method that allocates so much memory, precisely the first line of it (pre-ARC, it was way longer, but I reduced it to get the thing which creates allocations). When I remove it, the infinite allocations stop. Just a note again: This method gets called a really really lot of times a second, and on a different queue from main queue.
- (BOOL)obstacleIntersect {
UIView *view = [[self subviews] objectAtIndex:0];
return NO;
}
And this is how it looks in Allocations:
Mallocations
Thanks for any help and for reading, since you've just reached an end of this long question.
EDIT:
This is how the code should look with all the functionality etc. The reason I posted the code above with only one line is because now I don't care if it works like it should or not, I just want to solve the allocation problem. Sorry for misleading. As for the uiview particle, it is the view which intersects with already mentioned subviews. This code also produces same infinite allocations.
- (BOOL)obstacleIntersect {
for(UIView *view in [[[self subviews] objectAtIndex:0] subviews])
{
if (sqrt(pow(abs(particle.center.x - view.center.x), 2) + pow(abs(particle.center.y - view.center.y), 2)) < particle.frame.size.width / 2 - 1)
{
return YES;
}
}
return NO;
}
If this code is being called many many times, within one iteration of the run loop, and there are lots of items in subviews, you may be hitting a problem with the autorelease pool - the subviews array is autoreleased, for example, though I can't see why ARC doesn't remove it straight away. You could try wrapping the call to this method in its own autorelease block:
BOOL intersects;
#autoreleasepool { intersects = [self obstacleIntersect];}
// do something with intersects...
Though I freely admit that this is a guess.
See here for some documentation on local autorelease pools and why you'd want to use one.
Okay, I'm NOT new to Objective-C but I encountered a strange bug, that i have never seen before. Maybe I only made a small mistake and you're able to see it.
Within one of my functions I start by creating a new object from a custom view-class in the following way:
[buttonsBackground removeFromSuperview];
self.buttonsBackground = [[[PostCommentButtonsBackground alloc] initWithFrame:self.contentView.bounds] autorelease];
buttonsBackground.delegate = self;
But if I jump with the debugger over this block, the debugger claims that buttonsBackground would be a nil-pointer. But adding a NSLog right afterwards with
NSLog(#"%#",self.buttonsBackground);
still prints the line
<PostCommentButtonsBackground: 0x7bd27a0; frame = (0 0; 320 82); layer = <CALayer: 0x6e688b0>>
which clearly means, that it can't be nil. Does anybody have an idea how this can even be possible?
I am using the LLDB Debugger, not the GDB. The property buttonsBackground is declared as
#property(nonatomic, retain)PostCommentButtonsBackground *buttonsBackground;
so a missing retain isn't the case either.
EDIT: Okay, I just saw, that i'm not the only person with the exact same problem. There's another person with the same problem Debugger lldb says my object is nil when is not ?
I'm just leaving this post open anyway, because in the other post people kept claiming, the developer did a bad job with his memory management. In my post you can actually see, that this is not the case.
LLDB with the new Xcode 4.3 sometimes is totally lost, and using a NSLog instead of LLDB will show you that your initialized object is correctly initialized and not nil.
So, this is really a pain when you're in front of a bug.
I'm familiar with the delegate pattern and nilling my delegates, especially when doing asynchronous calls which are still in progress when my view controllers disappear. I nil the delegate, and the callback successfully returns on a nil object.
I'm now experimenting with using completion blocks to make my code a little easier to read.
I call a network service from my view controller, and pass a block which updates my UITableView. Under normal circumstances it works fine. However, if I leave the view before it completes, the completion handler block is executed - but the UITableView is now a zombie.
Whats the usual pattern for handling this?
UPDATE WITH CODE SAMPLE
This is an iPad app, I have two view controllers on screen at once, like a split view. One is the detail, and the other is a grid of images. I click an image and it tell the detail to load the info. However, if i click the images too fast before they have chance to do the network call - I have the problems. On changing images the code below is called which counts the favourites of a image....
So here is my dilemma, if I use the code below - it works fine but it leaks in instruments if you switch images before the network responds.
If I remove the __block and pass in self, then it crashes with zombies.
I can't win... I'm sure i'm missing something fundamental about using blocks.
__block UITableView *theTable = [self.table retain];
__block IndexedDictionary *tableData = [self.descriptionKeyValues retain];
FavouritesController *favourites = [Container controllerWithClass:FavouritesController.class];
[favourites countFavouritesForPhoto:self.photo
completion:^(int favesCount) {
[tableData insertObject:[NSString stringWithFormat:#"%i", favesCount]
forKey:#"Favourites:" atIndex:1];
[theTable reloadData];
[tableData release];
[theTable release];
}];
Any tips? Thanks
SECOND UPDATE
I changed the way I loaded the favourites. Instead of the favourites being a singleton, I create an instance on each photo change. By replacing this and killing the old one - the block has nowhere to callback (i guess it doesn't even exist) and my code now just looks like the below, and it appear to be working:
[self.favourites countFavouritesForPhoto:self.photo
completion:^(int favesCount) {
[self.descriptionKeyValues insertObject:[NSString stringWithFormat:#"%i", favesCount]
forKey:#"Favourites:" atIndex:1];
[self.table reloadData];
}];
It doesn't leak, and doesn't appear to be crashing either.
I recommend you test that the tableview is not nil at the start of the block. It sounds like the tableview is properly discarded when its parent view goes off-screen, so after that point, no tableview operations are valid.
Retaining the UITableView within the block is a bad idea, because datasource/tableview updates can result in implicit method calls and notifications that will not be relevant if the tableview is not on-screen.
Block will retain any object that it references, except for those annotated with __block. If you want not to execute completion blocks at all, just make some property like isCancelled and check whether it is YES before calling completion block.
So you have a background operation which has to call back another object after it finishes and the object can be destroyed in the meantime. The crashes you describe happen when you have non retained references. The problem as you see is that the referred object goes away and the pointer is invalid. Usually, what you do is unregister the delegate inside the dealloc method so that the background task continues, and whenever it is ready to communicate the results back it says "Shoot, my callback object is nil", and at least it doesn't crash.
Still, handling manually weak references is tedious and error prone. You can forget to nil a delegate inside a dealloc method and it may go without notice for months before you encounter a situation where the code crashes.
If you are targeting iOS 5.0 I would read up upon ARC and the weak references it provides. If you don't want to use ARC, or need to target pre 5.x devices, I would recommend using zeroing weak reference libraries like MAZeroingWeakRef which work also for 3.x devices.
With either ARC's weak references or MAZeroingWeakRef, you would implement the background task with one of these fancy weak reference objects pointing back to your table. Now if the pointed object goes away, the weak pointer will nil itself and your background task won't crash.
I am working on an iPad (only) app and I stumbled across a weird problem. The app gets terminated after a memory warning on iPad 1 but works fine on iPad 2.
I am using ARC and targeting iOS 5. I use nibs and most of my assets are displayed using UIImageViews. I also have a few hundred buttons and plenty of gesture recognizers... I re-watched the WWDC11 videos (sessions 323 and 322) on ARC and I don't seem to be doing anything special.
The app is UIImage intensive, I am doing lots of animations using UIImage. I am however using the initWithContentsOfFile constructor rather than the imageNamed call. I'm trying to prevent the images from being cached by the system.
I'm also using GCD to schedule sound effects and to animate views. I'm always doing this on the main thread.
The app uses a UINavigationController that never has more than 1 UIViewController on it's stack. I can confirm that this is true because the didReceiveMemoryWarning only gets called on the current view controller (I'm logging the call).
The thing I don't understand is why Instruments is reporting high numbers (as if the view controllers don't get deallocated) in both the Allocations and VM Tracker instruments. The Allocations instrument shows a small drop when I navigate from one view controller to another (which is what I expect) but the VM Tracker Instrument shows that the Dirty Size is not dropping when I do the same thing. Eventually the app uses too much memory and gets terminated (on iPad 1). When I get memory warnings on the iPad 2 the app does NOT get terminated though...
It feels as if my images, sounds or views don't get destroyed and the memory does not get reclaimed... My object hierarchy is very basic and there should not be any retain cycles of any sort. I don't even have simple delegates...
Do you have any suggestions? I really don't want to release this app only for the iPad 2 or newer... It's an app for kids and it would be a pitty... I'd be so much happier to learn that I'm doing something wrong, as I really want to make sure this app is the best it can be...
Cheers,
Nick
There are ways to say, 'optimise' your objects by setting their properties to nil when certain things aren't needed -- so while you can't write a dealloc method anymore, you can do self.object = nil (when pertinent) which ends up doing something like this in a non-ARC world for an 'retain' (i.e., strong) property:
- (void)setObject:(id)newObject
{
[object release]; // send release message to current object
object = newObject; // set reference to newObject
[object retain]; // send retain message to newObject
}
Now while in ARC you don't/can't write retain/release yourself in your code, the compiler inserts these calls for you, meaning that in practise, setting a property to nil would do this in the above example:
[object release]; // send release message to current object
object = nil; // set reference to nil
[object retain]; // send retain message to nil (no effect)
Moreover, this is just the tip of the iceberg -- you should make sure that there are no retain cycles in your code, which could be resulting in objects leaking without recourse to their destruction. This means, that there may be places where you're using strong references to a property (i.e., an object), when you should be using a weak property. The difference being, that strong references are retained, and weak references are assigned, the former having its retainCount incremented and the latter resulting in a property assignment that looks like this if handwritten:
- (void)setObject:(id)newObject
{
object = newObject;
}
I don't like answering my own question but I figured it could be helpful to future googlers. I implemented my own UIImage based animation and I no longer use the animationImages property. Turns out my memory issues are now gone as I no longer need to store all the images in memory and I load them as they are required using a timer.
I actually think that rolling out a custom animation is beneficial since it allows for callbacks and more powerful customisation options.
Once I'm happy with it and I feel like it's ready to be shared I will post the class(es) on GitHub.
I have a very simple code to show a modal controller (nextController is a class member):
nextController = [[InstructionsScreen alloc] initWithNibName:#"InstructionsScreen" bundle:nil];
[self presentModalViewController:nextController animated:YES];
[nextController release];
And then when the controller should hide:
[self dismissModalViewControllerAnimated:YES];
nextController = nil;
All works good as expected, but when I run instrument Object Allocations it shows that after dismissing the modal controller the memory it allocated is not freed. This becomes a problem because when I show several controllers the memory is over ...
Can anybody give me some clues ? Clang doesn't see any problems, so I'm stuck hitting the memory limit, because the memory of the dismissed controllers won't get released.
EDIT: What I discovered up to now is that it seems to be a leak somewhere in Apple's stuff. Way to reproduce: XCode -> create new project with the template "Utility application". Don't write any code yourself. Just create a new utility application and run it with "Object allocations", choose to see "Created & Still living". Now flip the modal controller few times - you'll see the allocated memory only grows and grows every time the modal controller is appearing and when it's disappearing too ...
There is no leak in the code you show as far as I can see. There could be a leak in InstructionsScreen that would prevent it being deallocated.
I think it's worth running the Static Analyser to see if it finds a leak.
The leak in the Apple template code is interesting. It could be that there is a leak. It seems unlikely but obviously it's not impossible. I would say that it's more likely that it's a false-positive in Instruments, which is why I'd suggest using the Static Analyser.
(You might want to raise a bug report about the leak.)
Modal views are not subviews of the calling view but are instead subview of the apps window and are retained by the window itself. You generally you do not retain a reference to them in the controller that calls them. Instead, evoke the modal view and then have it communicate with the controller by defining the controller as the modal view's delegate.
I think that if you use synthesize to create the accessor for a nextController property defined with retain, then the accessor will retain any object assigned to the property. Simply setting the value to nil will not release the object unless the accessor is set up to do that and I don't think the autogenerated ones do.
You will expressly have to call release before setting to nil.
If this doesn't work, post the code for your definition of the nextController property.