Memory leak to fix

Discussion in 'iOS Programming' started by boyplunder, May 29, 2009.

  1. boyplunder macrumors regular

    boyplunder

    Joined:
    Sep 8, 2008
    Location:
    UK
    #1
    Hi All,
    This is the only memory leak I seem to have left to deal with, but can't for the life of me see what's causing it. [Too many late nights maybe!]

    This leak is reported in instruments running in Simulator. [Still waiting for my enrollment to come through, so can't test on iPhone yet.] The code draws the name of an image from a field in a SQlite db and uses the same named image stored in a folder in Resources. Instruments highlights the first line starting 'UIImage...'.

    If anyone can chip in with a possible solution, thing to look for, or idea, I would be grateful.
     
  2. jnic macrumors 6502a

    Joined:
    Oct 24, 2008
    Location:
    Cambridge
    #2
    Presumably that's a retaining setter, which means you now have two references to termImage. Autorelease the first line.
     
  3. danielpunt macrumors newbie

    Joined:
    Oct 11, 2007
    Location:
    Netherlands
    #3
    Do you release the image?
    Code:
    [termImage release];
     
  4. boyplunder thread starter macrumors regular

    boyplunder

    Joined:
    Sep 8, 2008
    Location:
    UK
    #4
    Yes, it is a retain issue and I haven't released it. Well spotted.
    Early to bed tonight!

    Thanks for your help.
     
  5. BlackWolf macrumors regular

    Joined:
    Apr 9, 2009
    #5
    btw, instead of autoreleasing you can also use
    termView.termImage.image = termImage;
    (without the self.), which will be an assignment and nothing gets retained.
     
  6. PhoneyDeveloper macrumors 68030

    PhoneyDeveloper

    Joined:
    Sep 2, 2008
    #6
    Blackwolf, but of course that would be a memory leak unless you do that in an init method. In addition, since it seems he his groping the image property of another object, it probably won't work as you suggest.
     
  7. boyplunder thread starter macrumors regular

    boyplunder

    Joined:
    Sep 8, 2008
    Location:
    UK
    #7
    PhoneyDeveloper,
    I love your use of the word 'groping'. Makes me think I'm using a less than elegant way of doing this. I did try using an imagenamed approach, but couldn't get it quite right.

    I would appreciate any guidance or pointers you may have.
     
  8. admanimal macrumors 68040

    Joined:
    Apr 22, 2005
    #8
    You would be correct if there weren't nested properties there. So if it was self.myImage = termImage versus myImage = termImage then yes, the lack of self. would mean that the 2nd assignment doesn't retain termImage. However, image is not a property of self; it's a property of termView.termImage and presumably termView.termImage -is- going to retain its image property, and there would be a memory leak.
     
  9. BlackWolf macrumors regular

    Joined:
    Apr 9, 2009
    #9
    yeah, well, I assumed he will release the image afterwards of course :D

    yeah, right, I didn't think of that.
     
  10. PhoneyDeveloper macrumors 68030

    PhoneyDeveloper

    Joined:
    Sep 2, 2008
    #10
    BoyPlunder,

    Well-mannered objects don't touch the private parts of other objects.

    This is part of good design. Encapsulation. Strictly speaking, the property syntax of Obj-C 2.0 is meant to make it easier to provide encapsulation. Your getter/setter protects the ivars from being, ahem, groped, by other objects. And that's a good thing. They also help developers to get the retain/copy/release memory management code correct.

    However, in most cases properties are public and that may invite unwanted touching from other objects. And that's not usually a good thing.

    In the example you showed your code was setting the image property of something that was, or could have been, a UIImageView. UIImageView is designed to allow setting of its image property in a public way. Setting the property obviously does other things besides just set an instance variable. It makes the image view redraw itself, for instance. So in your case the setting of the image property was public and was invited, which is ok.

    My point is that you should design your classes in such a way that any uninvited setting of properties doesn't screw things up. In fact there's almost always a way to go around any protections that you put in to make things private. The design of Obj-C explicitly lets you send any message to any object and lets you set the ivars on any object so there's a limit to how much you can do to make things private.
     

Share This Page