I'm working up a graphics effect for an iPhone app that simulates a low-res plasma effect from old demoscene days. I've got 600 squares on screen that are updating as fast as possible. Since I am using CoreGraphics (for now), I can get a very constant 11FPS with no freezing--
BUT when I try to add one simple NSArray lookup, the iPhone as well as the simulator freezes for several seconds every few seconds. I've run this in instruments and it says there is a leak -- the leak has to do with NSAutoReleasePool, but that doesn't really help. (I am creating an NSAutoReleasePool at the beginning of every update frame and draining the pool at the end.)
By process of elimination, I've been able to narrow it down to one line that's causing the slowdown. This line happens for each of the 600 block sprites each frame update:
//SLOOWWWNESS /LEAKING NSAUTORELEASEPOOL IS here (freezing every second or so)
UIColor *color = [palette objectAtIndex:colorNum];
//BUT DOESNT HAPPEN HERE... (works at full speed)
UIColor *color = [UIColor colorWithRed:0.25f green:0.25f blue:colorNum/15.0 alpha:1.0f];
... where palette is a NSArray property in the sprite, and contains a list of UIColor objects that I've created. This array of UIColor objects is created only once, when the app launches, and all sprites are using the same array.
Anyone have any ideas?
What is colorNum? Could it ever be some crazy value outsides the array's bounds?
Is palette a 'retain' property... the palette object really has been retained, right? Is it synthesized, or have you implemented your own getPalette method?
Related
I have an iPhone app where I'm "adding" a lot of CGColors together by breaking them down into their components, averaging the components, and then making a new color with the new components. When I run this code, Instruments finds that I'm leaking lots of CGColors, and the app runs slowly.
I feel like I could solve the memory leak issue if there were a way to do what I'm doing without using CGColorCreate(colorspace, components) every time.
This is the code for the color "adding"
const CGFloat *cs=CGColorGetComponents(drawColor);
const CGFloat *csA=CGColorGetComponents(add->drawColor);
CGFloat r=(cs[0]*w+csA[0]*aW)/1;
CGFloat g=(cs[1]*w+csA[1]*aW)/1;
CGFloat b=(cs[2]*w+csA[2]*aW)/1;
CGFloat components[]={r, g, b, 1.f};
drawColor=CGColorCreate(CGColorSpaceCreateDeviceRGB(), components);
Any help would be really appreciated, even if the help is "add the colors less often." I'm sure I'm not the only person trying to modify CGColors.
EDIT: So, rob's comment put me on the right track, but I'm getting malloc double free errors because the method with the color adding is called multiple times before a new drawColor is assigned. Is there a way to check whether drawColor exists before I release it? Here is the new relevant code.
CGColorSpaceRef colorSpace=CGColorSpaceCreateDeviceRGB();
CGColorRelease(drawColor);
drawColor=CGColorCreate(colorSpace, components);
CGColorSpaceRelease(colorSpace);
Pretty sure you just need to CGColorRelease(drawColor) to prevent the leak. See how that helps your performance.
If you're leaking CGColor objects, the first step to solving your problem is to stop leaking them. You need to call CGColorRelease when you're done with a color object. For example, you are obviously leaking the drawColor object in your example code. You should be doing this:
CGColorRelease(drawColor);
drawColor=CGColorCreate(CGColorSpaceCreateDeviceRGB(), components);
to release the old object referenced by drawColor before you assign the new object to drawColor.
CGColor objects are immutable, so you won't be able to just modify your existing objects.
I have a scene called Level1, which takes the hero and the enemy from a layer called GameLayer. I heard that an efficient way of doing this is using tags and retrieving it using getChildByTag. I tried this out, but I'm having many issues. I'm using SneakyInput. On Level1, there is a leftJoystick (for enemy movement), and a rightJoystick (for firing projectiles). I have an addEnemy and addHero method in my GameLayer, which I call. Everything I've mentioned works.
In my Level1 scene I have a method called moveHero (which obviously is supposed to move the hero with the joystick.). Through basic debugging I know the problem is the geteChildByTag line. I test out the hero's position through NSLog, and it's saying 0,0. Which is weird because on screen you can see the hero. But I also realized I'm calling the addHero method without using getChildByTag.
I hope I'm being clear here. I've uploaded GameLayer.h and GameLayer.m onto 4shared. http://www.4shared.com/file/PqhjoMFy/GameLayer.html
Hopefully you can take a look at it and point me in the right direction.
BTW: There are no errors or crashes. It's just not working.
Thanks in advance.
getChildByTag will never crash, it's a pretty nicely coded method that just loops through the children array of the object and checks to see if any objects match, that way you don't get assertion issues.
You have some serious issues here with your code.
Firstly..
GameLayer *heroInstance = [[GameLayer alloc] init];
CCSprite *hero = (CCSprite *)[heroInstance getChildByTag:1];
NSLog(#"Hero position X: %f", hero.position.x);
NSLog(#"Hero position Y: %f", hero.position.y);
This will never work, heroInstance is a brand new object, it has no children, also you've just created a memory leak here.
Your hero is a child of the spritesheet, which is a child of the scene.
To reference your child you must call getChildByTag on your spritesheet (which you probably need to reference by calling getChildByTag on your scene..
something like this.
[[self getChildByTag:spritesheet] getChildByTag:hero];
Also, use an enum, so that you don't have to remember what numbers certain tags are (look at the cocos2d example projects).
I have a UITableView where numberOfSectionsInTableView and numberOfRowsInSection are being called twice, with scope issues on the second run. If I mask the problem, I get a scope issue on the first run of cellForRowAtIndexPath.
Most data all comes from an NSDictionary which is configured during viewDidLoad. I also have an NSArray configured at the same time. Once set they are never changed nor released.
When numberOfSectionsInTableView is called the first time, it's fine. Counts the elements as needed etc. It's then immediately called a second time (no idea why). On the second run, it cannot access the NSDictionary or NSArray items. Crash even when trying to NSLog them. For example:
NSLog(#"theMainDictionary %#",theMainDictionary);
usually results in EXC_BAD_ADDRESS but occasionally something like this:
theMainDictionary <_UITableViewSeparatorView: 0x4e73680; frame = (0 307; 320 1); opaque = NO; autoresize = W; layer = <CALayer: 0x4e4bf20>>
Again, this same line runs fine (logging the dictionary as expected) the first run through.
If I mask the problem by returning a fixed NSInteger, numberOfRowsInSection then does the same thing. If I mask numberOfRowsInSection, cellForRowAtIndexPath crashes on the first run. Same issue though - can't access theMainDictionary or the related NSArray.
I can't figure out why they're running twice - there's no reloadData anywhere. Nor do I know why the second call runs any differently. Any assistance greatly appreciated.
You're probably creating your dictionary with [NSDictionary dictionary] or one of the several similar factory methods (which returns an autoreleased instance), and then saving it directly to an ivar without retaining it. It will work fine until your program gets back to the main run loop, at which time the autorelease will resolve and the object gets freed.
There are a few ways to fix it:
Assign to a property declared retain rather than an ivar. This means self.theMainDictionary rather than just theMainDictionary. This will retain it for you, so it will stick around until you release it (or assign a different dictionary or nil to the property).
Use [[NSDictionary alloc] init] (or one of the many other init methods) rather than [NSDictionary dictionary] style. This returns an instance that you own, so it will stick around until you release it.
Explicitly call retain on the dictionary when saving it to the ivar. This takes ownership, so it will stick around until you release it.
In all cases, do remember to release the dictionary in your dealloc method, or the memory will leak.
All of the above probably applies to the array too. See Apple's documentation for a much more detailed explanation of memory management in Cocoa.
I ran a few stress tests on my Iphone app. The results are below. I am wondering if I should be concerned and, if so, what I might do about it.
I set up a timer to fire once a second. Whenever the timer fired, the app requested some XML data from the server. When the data arrived, the app then parsed the data and redisplayed the affected table view.On several trials, the app averaged about 500 times through the loop before crashing.
I then removed the parsing and redisplay steps from the above loop. Now it could go about 800 times.
I set up a loop to repeatedly redisplay the table view, without downloading anything. As soon as one redisplay was completed, the next one began. After 2601 loops, the app crashed.
All of the above numbers are larger than what a user is likely to do.
Also, my app never lasts long at all when I try to run it on the device under instruments. So I can't get useful data that way. (But without instruments it lasts quite a while, as detailed above.)
I would say you need to be very concerned. The first rule of programming is that the user will never do what you expect.
Things to consider:
Accessor methods. Use them. Set up
properties for all attributes and
always access them with the
appropriate getter/setter methods:
.
object.property = some_other_object; -OR-
[object setProperty:some_other_object];
and
object = some_other_object.some_property;
object = [some_other_object some_property];
Resist the temptation to do things like:
property = some_other_object;
[property retain];
Do you get output from ObjectAlloc?
There are 4 tools from memory leaks,
performance and object allocations.
Are none of them loading?
What do you get when the app crashes?
EXEC_BAD_ACCESS or some other error?
Balanced retain (either alloc or
copy) and release. It is a good idea
to keep every alloc/copy balanced
with a release/autorelease in the
same method. If you use your
accessors ALL OF THE TIME, the need
for doing manual releases is seldom.
Autorelease will often hide a real
problem. It is possible Autorelease
can mask some tricky allocation
issues. Double check your use of
autorelease.
EDITED (Added based on your fault code)
Based on your above answer of "Program received signal: 0". This indicates that you have run out of memory. I would start by looking for instances that your code does something like:
myObject = [[MyClass alloc] init];
[someMutableArray addObject:myObject];
and you do not have the "release" when you put the new object into the array. If this array then gets released, the object, myObject, will become an orphan but hang around in memory anyway. The easy way to do this is to grep for all of your "alloc"/"copy" messages. Except under exceedingly rare conditions, there should be a paired "release""/autorelease" in the same function. More often than not, the above should be:
myObject = [[[MyClass alloc] init] autorelease];
[someMutableArray addObject:myObject];
I'm trying to keep track of my sprites in an array, add and remove
them from layers, and then finally clear them out of the array.
I'm using the following code:
Sprite * Trees[50];
Layer * Forest;
Forest = [Layer node];
Forest.isTouchEnabled = YES;
[self addChild:Forest z:30];
// do this a bunch of times
Trees[0] = [[Sprite spriteWithFile:#"mytree.png"] retain];
[Trees[0] setPosition:cpv(240,160)];
[Forest addChild:Trees[0] z:5];
And then when I want to destroy a tree I use:
[Forest removeChild:Trees[0] cleanup:YES];
[Trees[0] release];
My problem is that when I look in Instruments, I'm never reclaiming
that memory, there is never a drop back down. I thought that by
releasing the sprite it would free up the memory. Am I doing this
completely wrong?
I know that when you are using the simulator with cocos2d, the memory doesn't look like it's being released, so you have to run it on the device to get an accurate picture of what's going on.
There is a good discussion here about cocos2d and memory.
What I've noticed is that everything that you create and retain must be released, but it isn't released from memory until I do this:
[[TextureMgr sharedTextureMgr] removeAllTextures];
That will release the memory.
Here's a bigger example:
Sprite * sPopup = [[Sprite spriteWithFile:#"popup.png"] retain];
sPopup.position = cpv(240,440);
[self addChild: sPopup z:2];
[sPopup release];
Then, when I'm done with sPopup in another function I have this:
[[TextureMgr sharedTextureMgr] removeAllTextures];
and the memory is freed.
My suspicion is that you are "over" retaining:
Trees[0] = [[Sprite spriteWithFile:#"mytree.png"] retain];
If Trees is a local variable in a function you do not have to retain in that case if spriteWithFile is returning a Sprite with an autorelease.
The section on delay release in the apple documentation discusses this further. The long and short of it is that the receiver of the autorelease is guaranteed to have the object be valid for the duration of its scope. If you need the object beyond the scope of the function (e.g. Trees is a property of a class) then yes, in that case you need a retain (or just synthesize a property configured to retain).
By issuing the extra retain, it is likely that your retain count is always too high (never reaches 0) and hence your object is not garbage collected.
For good measure, I'd suggest reviewing this paragraph as well that talks about the validity of objects.
Even though you call [Trees[x] release], I believe you still need to 'delete' the item from the array, like Trees[x] = nil or something, as the array itself is still containing the object.
The 'retain' in the Sprite creation is also not necessary, as [Forest addChild:z:] will place a retain on it as well (afaik).