Register FAQ / Rules Forum Spy Search Today's Posts Mark Forums Read
Go Back   MacRumors Forums > Apple Systems and Services > Programming > iPhone/iPad Programming

Reply
 
Thread Tools Search this Thread Display Modes
Old Aug 18, 2012, 02:41 PM   #1
IDMah
macrumors regular
 
Join Date: May 2011
retain UIColor

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
IDMah is offline   0 Reply With Quote
Old Aug 18, 2012, 02:47 PM   #2
jnoxx
macrumors 65816
 
jnoxx's Avatar
 
Join Date: Dec 2010
Location: 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
__________________

iPad Mini, iPad 4, iPad 2, iPhone 3G,4,5, iMac 24", Mac Mini Last gen, Macbook Pro Retina with Dell U2711
jnoxx is offline   0 Reply With Quote
Old Aug 18, 2012, 03:46 PM   #3
chown33
macrumors 603
 
Join Date: Aug 2009
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.
chown33 is offline   0 Reply With Quote
Old Aug 18, 2012, 09:38 PM   #4
Duncan C
macrumors 6502a
 
Duncan C's Avatar
 
Join Date: Jan 2008
Location: Northern Virginia
 
see vendor information in user profile
Quote:
Originally Posted by IDMah View Post
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.
__________________
Regards,
Duncan Champney, WareTo.
Check out our latest iOS app, Face Dancer, available for free on the App Store.
Duncan C is offline   0 Reply With Quote
Old Aug 19, 2012, 01:26 PM   #5
IDMah
Thread Starter
macrumors regular
 
Join Date: May 2011
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
IDMah is offline   0 Reply With Quote
Old Aug 19, 2012, 01:49 PM   #6
chown33
macrumors 603
 
Join Date: Aug 2009
Quote:
Originally Posted by IDMah View Post
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.
chown33 is offline   0 Reply With Quote
Old Aug 19, 2012, 03:05 PM   #7
IDMah
Thread Starter
macrumors regular
 
Join Date: May 2011
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 by IDMah; Aug 19, 2012 at 03:20 PM.
IDMah is offline   0 Reply With Quote
Old Aug 19, 2012, 04:45 PM   #8
chown33
macrumors 603
 
Join Date: Aug 2009
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.
chown33 is offline   0 Reply With Quote
Old Aug 20, 2012, 12:41 PM   #9
phr0ze
macrumors 6502
 
Join Date: Jun 2012
Location: 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.
__________________
2012 11" MBA i7/8/256
2011 Mac Mini with 27" Thunderbolt Display
Black iPad Air 64GB Verizon
Black iPhone 5S 32GB ATT
phr0ze is offline   0 Reply With Quote
Old Aug 21, 2012, 01:43 PM   #10
IDMah
Thread Starter
macrumors regular
 
Join Date: May 2011
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
IDMah is offline   0 Reply With Quote
Old Aug 21, 2012, 02:00 PM   #11
chown33
macrumors 603
 
Join Date: Aug 2009
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.
chown33 is offline   0 Reply With Quote
Old Aug 21, 2012, 03:18 PM   #12
Duncan C
macrumors 6502a
 
Duncan C's Avatar
 
Join Date: Jan 2008
Location: Northern Virginia
 
see vendor information in user profile
Quote:
Originally Posted by IDMah View Post
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.)
__________________
Regards,
Duncan Champney, WareTo.
Check out our latest iOS app, Face Dancer, available for free on the App Store.
Duncan C is offline   0 Reply With Quote

Reply
MacRumors Forums > Apple Systems and Services > Programming > iPhone/iPad Programming

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT -5. The time now is 09:42 AM.

Mac Rumors | Mac | iPhone | iPhone Game Reviews | iPhone Apps

Mobile Version | Fixed | Fluid | Fluid HD
Copyright 2002-2013, MacRumors.com, LLC