Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.

IDMah

macrumors 6502
Original poster
May 13, 2011
316
11
So I tracked a random bug to :

Code:
   [self setCardColour:[UIColor colorWithRed:0.6 green:0.0 blue:0.0 alpha:1.0]];

// if I changed it to this:
   [self setCardColour:[UIColor colorWithRed:0.6 green:0.0 blue:0.0 alpha:1.0]retain]];

//but I think it caused a memory leak. 
// if I changed it to this:
   [self setCardColour:[[UIColor alloc] initWithRed:0.6 green:0.0 blue:0.0 alpha:1.0]];
                        
// would that be better worse or the same??

thanks
Ian
 

jnoxx

macrumors 65816
Dec 29, 2010
1,343
0
Aartselaar // Antwerp // Belgium
[self setCardColour:[UIColor colorWithRed:0.6 green:0.0 blue:0.0 alpha:1.0]retain]];

This is creating an autoreleased UIColor, but still retaining it (means you WILL have to release it, this is bad ;p).
But it's the same as -> [self setCardColour:[[UIColor alloc] initWithRed:0.6 green:0.0 blue:0.0 alpha:1.0]];

You still have a color which you have the retain count of, so you're still in charge of releasing it :)
 

chown33

Moderator
Staff member
Aug 9, 2009
10,706
8,346
A sea of green
Post the code for setCardColour:. The complete method, not just part of it.

If you're doing a retain outside of a setter method, you're doing it wrong. All the responsibility for maintaining the lifetime of an object should be in the setter and getter methods. That's why there are methods in the first place. If all it took for proper lifetime control was assigning a value to an ivar, no method would be needed at all. It's the fact that simple assignment isn't enough that there are accessor methods.

And is there some reason you're not using a property with synthesized accessors? They allow a much more concise definition of semantics (i.e. the question of copy, retain, atomicity), and the simplest implementation mechanism possible: the @synthesize keyword.
 

Duncan C

macrumors 6502a
Jan 21, 2008
853
0
Northern Virginia
So I tracked a random bug to :

Code:
   [self setCardColour:[UIColor colorWithRed:0.6 green:0.0 blue:0.0 alpha:1.0]];

// if I changed it to this:
   [self setCardColour:[UIColor colorWithRed:0.6 green:0.0 blue:0.0 alpha:1.0]retain]];

//but I think it caused a memory leak. 
// if I changed it to this:
   [self setCardColour:[[UIColor alloc] initWithRed:0.6 green:0.0 blue:0.0 alpha:1.0]];
                        
// would that be better worse or the same??

thanks
Ian


Somebody else hinted at the solution. Make cardColor a retained property:

Code:
@property (nonatomic, retain) cardColor;

Then the act of setting a card color will cause the property to retain the color. (More precisely, the setter method for cardColor will retain the color you pass in, after releasing any old value in cardColor.)

The last bit of that is that in your object's dealloc, you need to set self.cardColor to nil. That will release a cardColor object if there is one.
 

IDMah

macrumors 6502
Original poster
May 13, 2011
316
11
Actually I do make it a property.

Code:
@property (nonatomic,retain) UIColor *cardColour;

but I saw somewhere that:
Code:
[UIColor colorWithRed:0.6 green:0.0 blue:0.0 alpha:1.0];
// needs a retain or the above crashes... 
// where as 
[UIColor redColor]];
// Doesn't

no Idea why. starting to think I may have to live with it, I do release it later.
I do mix and match

Code:
[self setCardColour:[UIColor colorWithRed:0.6 green:0.0 blue:0.0 alpha:1.0]];
[self setCardColour:[UIColor blackColor]];

could that be the problem ??? Ugh grasping at straws..
thanks
Ian
 

chown33

Moderator
Staff member
Aug 9, 2009
10,706
8,346
A sea of green
Actually I do make it a property.

But are the accessors synthesized? Or did you write a setCardColour: method?


Somewhere, some code is over-releasing or under-retaining the card-color object. You need to find that code.

Run your program with zombies enabled. When the over-release or under-retain occurs, the next access of the object will be a zombie access. Use that to find the code doing the over-release or under-retain.

Running with zombies enabled is something that every programmer should do regularly, like once a week, or even daily. If you have any zombie objects at all, it indicates incorrect memory management. Fix it before it gets out of hand.


Is there any code that does direct access of the ivar? If you believe not, then change your @interface to have no declared ivar, and let @synthesize create both the accessors and the ivar. That way there's no chance of an accidental reference of the direct ivar.

If your code won't compile after removing the ivar, then you've found your direct ivar access. Start debugging there, because someone may be doing an over-release or under-retain of the directly referenced ivar.
 

IDMah

macrumors 6502
Original poster
May 13, 2011
316
11
Yeap:
Code:
@synthesize cardColour;

Generic synthesize no ivars. This is my first app so new to instruments.

Zombies is showing a gazillion allocs:
Code:
GSEventRunModal(s)

but zero zombie alerts.

Also doesn't help that on SnowLeopard Instruments crashes a lot. Like right now.. eesh !!! I know I need to fix this but I've been slamming my face with a brick for 2 weeks now.. since the crash only happens after playing 10-20 games.. Which I reckon means it is memory release related.



with a fear of making you scream...
the only direct access to it is which shouldn't do anything?? :
Code:
	UIColor * tempColor =[[self.board objectAtIndex:fromCardIndex] cardColour];
       [tempColor retain];
	// blah blah stuff ... 
        [self.board objectAtIndex:toCardIndex] setCardColour:tempColor];
        [tempColor release];

thanks for helping a stupid guy..
Ian
 
Last edited:

chown33

Moderator
Staff member
Aug 9, 2009
10,706
8,346
A sea of green
How many different colors do you need? If it's a relatively small number, why not centralize it using a Singleton pattern. Create one instance of every color needed. Make a centralized method (often a class method) that dispenses the single object to all callers. Since the singleton itself has ownership, i.e. an outstanding retain, and all callers will also do a retain (and a release), you should end up with a net +1.

You can then write debug code that checks on net retain-counts. Sorta your own specialized version of zombies. It only checks the singleton colors. It knows many times the singleton dispenser method has been called. If the retain-counts are decreasing when they shouldn't be, then define your own subclass of UIColor and override retain & release to keep even closer track.

This may be an extreme measure, and it may not even work. But if zombies isn't working, you need an alternative.

You could also just brute-force the problem into oblivion. When making the singleton colors, call retain 1000 times on each one. If your game avoids runs that last years on end, that should be big enough to just brute-force the problem away.
 

phr0ze

macrumors 6502a
Jun 14, 2012
513
0
Columbia, MD
Or your problem is somewhere else and your program is just happening to crash here due to how frequently the code is used.
 

IDMah

macrumors 6502
Original poster
May 13, 2011
316
11
zombie or Leaks?

I was and am considering that the error is elsewhere but, some evidence to supports my idea.

the compile after I remove the retain. the App crashes when I shuffle or reset the buttons. It's an array of buttons and an object that feeds that..

Sort of related. do I trust zombies Allocations or leaks? Leaks says my memory is fairly (stable) consistent in size. While Zombies the number keeps growing?

thanks for everyones help.
later
Ian
 

chown33

Moderator
Staff member
Aug 9, 2009
10,706
8,346
A sea of green
You don't understand how zombies work. When zombies are enabled, the memory consumption will always increase. That's because every object that would normally be dealloc'ed will instead become a zombie object. So it still exists, but it's a zombie. No objects ever truly die, and no memory ever gets used. In a world... with zombie objects... nothing ever truly dies.

You should probably reread the memory management guide.
 

Duncan C

macrumors 6502a
Jan 21, 2008
853
0
Northern Virginia
I was and am considering that the error is elsewhere but, some evidence to supports my idea.

the compile after I remove the retain. the App crashes when I shuffle or reset the buttons. It's an array of buttons and an object that feeds that..

Sort of related. do I trust zombies Allocations or leaks? Leaks says my memory is fairly (stable) consistent in size. While Zombies the number keeps growing?

thanks for everyones help.
later
Ian

Your post is alphabet soup. There are grammar mistakes in just about every sentence, making it hard to understand what you are trying to say.

The other poster answered your question I think.

Zombies are objects that are over-released, and likely causes of a crash. Zombies will not show your amount of available memory going down. Zombies are "undead objects" that should be dead, but your program doesn't know it.

Leaks are objects that you don't release once you are done with them. The memory is lost, so the amount of memory available to your program goes down as the leaks accumulate. Your program can run without symptoms if you have a fixed number of small leaks. (If you leak 2 5 byte objects at startup, and never any more, you won't notice the difference.) Leaks can cause crashes if your program runs out of memory as a result.

(Analogy. A leak of few liters of water on the floor of your ship that you spill in once, and never repeat, won't sink the ship. A slow, steady leak of a few liters/hour can sink your ship if the leak is allowed to continue for enough time. Let a single zombie loose on your ship, though, and sooner or later, somebody is going to trip over it and their brains will get eaten.)
 
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.