• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: NSImage TIFFRepresentation memory leak
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: NSImage TIFFRepresentation memory leak


  • Subject: Re: NSImage TIFFRepresentation memory leak
  • From: j o a r <email@hidden>
  • Date: Fri, 1 Dec 2006 14:06:59 +0100


On 1 dec 2006, at 09.33, Hidetomo Katsura wrote:

FYI, this is a textbook case of an OS leak. you (or at least i) can easily tell from the backtrace. you are only responsible for releasing a reference that's returned by a method or function. just file a bug and move on. if it's a significant leak, you have to come up with a workaround.

in this case, a reference returned by CGLCreateContext (or allocate_context. it doesn't matter) is the leak, and it was never returned to you since -[NSImage TIFFRepresentaion] only returns an autoreleased NSData object (not a CGLCreateContext). obviously, you can't directly release a reference returned by CGLCreateContext since you don't even have access to it.

in short, if you didn't create (allocate, copy, or retain) it, it's not your leak.


Based on the data presented in this thread so far I would not agree that your claim is necessarily true.

ObjectAlloc shows backtraces to things that are allocated, but that's not the same thing as leaked.
If the piece of data that is allocated in this backtrace is still live, that is most likely because its "owner" has not released / freed it yet. Note that the "leak event" is typically not the same thing as the allocation event!


Presented with something that could be either [1] a memory leak in a framework, or [2] a memory leak in your code, you should always suspect your code - Unless the evidence to the contrary is overwhelming.

In this case we don't even know what's being leaked - is it opaque malloced data? It should be of primary interest to see if the NSData instances returned from "-TIFFRepresentation" are leaked or not. This, and many other similar points of data, is still unknown.

The best thing would of course be if this proposed leak could be isolated in a small sample program, and posed for others to have a look at.

I'm not saying that you're necessarily wrong, only that I don't think we have enough information to assert that you're right.

j o a r


Attachment: smime.p7s
Description: S/MIME cryptographic signature

_______________________________________________

Cocoa-dev mailing list (email@hidden)

Do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:

This email sent to email@hidden

  • Follow-Ups:
    • Re: NSImage TIFFRepresentation memory leak
      • From: Daniel Jalkut <email@hidden>
References: 
 >Re: NSImage TIFFRepresentation memory leak (From: Hidetomo Katsura <email@hidden>)

  • Prev by Date: Re: Checking if a file is Locked [SOLVED]
  • Next by Date: Re: NSImage TIFFRepresentation memory leak
  • Previous by thread: Re: NSImage TIFFRepresentation memory leak
  • Next by thread: Re: NSImage TIFFRepresentation memory leak
  • Index(es):
    • Date
    • Thread