Re: [Pyobjc-dev] Memory management bug using .new() -- and another one?
Brought to you by:
ronaldoussoren
From: Ronald O. <ron...@ma...> - 2009-07-08 11:58:48
|
On 8 Jul, 2009, at 13:51, Dirk Stoop wrote: > Hi Ronald, > > Thanks for this. No worries about taking a while to get to it, I'm > very grateful. :) > > I'll check out r2261 to see if I can start using that revision > (still on 2.2b2 right now) for Checkout. > > Looking at where the problem lies, this probably also fixes the > problems I encountered with .new() before. Funny how those two > issues seem to be related again. Maybe not, the +new issue is separate from this issue. The two-line explanation for that issue: * The real world: +new { return [[self alloc] init]; } * PyObjC's world: +new { return [[[self alloc] init] autorelease]; } This causes refcount leaks because PyObjC doesn't know that it owns the reference that new returns, and hence should call -release sometime later. I have a fix for that in my tree, but that's to intertwined with SL related code to easily push to the repository. The easiest workaround for now: don't use 'SomeClass.new()' but use 'SomeClass.alloc().init()'. Ronald > > Thanks again, > - Dirk > > On Jul 8, 2009, at 1:14 PM, Ronald Oussoren wrote: > >> Refcounts are annoying.... Actually understanding what was going >> wrong was slightly harder than I had expected, but I managed to >> find and fix the bug. >> >> The end of the output of your example when I close the window is now: >> >> 2009-07-08 13:05:24.955 TopLevelLeaker[71318:903] dealloc in >> <TLWindowController: 0x104d46780> >> 2009-07-08 13:05:24.957 TopLevelLeaker[71318:903] dealloc in >> <TLPythonInitView: 0x104d49d50> >> 2009-07-08 13:05:24.958 TopLevelLeaker[71318:903] dealloc in >> <TLVanillaArrayController: 0x104f71b40>[object class: >> NSMutableDictionary, number of selected objects: 0] >> 2009-07-08 13:05:24.959 TopLevelLeaker[71318:903] dealloc in >> <TLVanillaView: 0x104f76140> >> 2009-07-08 13:05:24.961 TopLevelLeaker[71318:903] dealloc called in >> <TLPythonInitArrayController: 0x104f72110>[object class: >> NSMutableDictionary, number of selected objects: 0] >> >> As you can see the program now correctly deallocs both the >> PythonInitView and the VanillaView. >> >> I've committed the fix as r2261. This is however a partial commit >> from my working tree, I'm pretty sure I included just the right >> amount of changes to truly fix the issue. I cannot do a full commit >> at the moment because my working tree contains SnowLeopard-related >> code which cannot be released because SL is under NDA. >> >> Ronald >> >> On 8 Jul, 2009, at 11:35, Ronald Oussoren wrote: >> >>> Dirk, >>> >>> Sorry about the slow response, it's busy at work and haven't been >>> able >>> to find time to dive into this until now. >>> >>> The good news is that this issue is unrelated to NIB files, making >>> it >>> a lot easier to debug than I feared that it would be. The bad news >>> is >>> that there seems to be a serious memory leak in PyObjC when >>> instances >>> are created in ObjC code but have a Python initializer. >>> >>> I currently have a testcase with some ObjC code that calls [[cls >>> alloc] init] on an arbitrary class. When I create an object using >>> this >>> code in class that has a Python init method, the instance is never >>> released. When the (Python) class does not have a Python init method >>> it will be released. >>> >>> Now that I have a pretty simple testcase that reproduces the issue >>> I'm >>> hopeful that I'll be able to fix the issue soon, and keep it fixed. >>> The failure mode also points to a fairly specific path through the >>> code, which should help in pinpointing the issue. >>> >>> BTW. This does not affect creating new instances from Python code, >>> which is probably why this is only really noticable in some specific >>> contexts. >>> >>> Ronald >>> >>> On 23 Jun, 2009, at 14:52, Dirk Stoop wrote: >>> >>>> Hi Ronald, >>>> >>>> A sample app that demonstrates the isolated issue is attached. See >>>> the README.txt in the archive for a quick overview. >>>> >>>> <TopLevelLeaker.zip> >>>> >>>> Cheers, >>>> -Dirk >>>> >>>> On Jun 23, 2009, at 10:55 AM, Ronald Oussoren wrote: >>>> >>>>> Dirk, >>>>> >>>>> On 23 Jun, 2009, at 10:32, Dirk Stoop wrote: >>>>> >>>>>> Hi Ronald, >>>>>> >>>>>> I use objc.IBOutlet() all over the place, so I've tried a >>>>>> couple of >>>>>> things. >>>>> >>>>> I just thought of an easier way to do this: before importing any >>>>> PyObjC classes do: import objc; objc.IBOutlet = objc.ivar. I >>>>> wonder >>>>> why I didn't think of that earlier :-( >>>>> >>>>>> >>>>>> Short summary is: It definitely changes behavior, but it doesn't >>>>>> solve the problem. >>>>>> >>>>>> I've tried the following things: >>>>>> >>>>>> 1. Add an objc.ivar() definition (with the same name) after an >>>>>> outlet definition to a top-level object that has an init method >>>>>> implemented in Python. >>>>>> 2. Add an objc.ivar() definition (with the same name) after an >>>>>> outlet definition to a top-level object that's a vanilla Cocoa >>>>>> class. >>>>>> 3. Add an objc.ivar() definition (again, the same name) after an >>>>>> outlet definition to a non-top-level object that's implemented >>>>>> with >>>>>> Python, but doesn't override the designated initializer. >>>>> >>>>> Could you create a small application that demonstrates the >>>>> problem? >>>>> That would make testing on my side a lot easier. >>>>> >>>>> Ronald >>>>> >>>>> >>>>> ------------------------------------------------------------------------------ >>>>> Are you an open source citizen? Join us for the Open Source Bridge >>>>> conference! >>>>> Portland, OR, June 17-19. Two days of sessions, one day of >>>>> unconference: $250. >>>>> Need another reason to go? 24-hour hacker lounge. Register today! >>>>> http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org >>>>> _______________________________________________ >>>>> Pyobjc-dev mailing list >>>>> Pyo...@li... >>>>> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev >>>> >>>> ------------------------------------------------------------------------------ >>>> Are you an open source citizen? Join us for the Open Source Bridge >>>> conference! >>>> Portland, OR, June 17-19. Two days of sessions, one day of >>>> unconference: $250. >>>> Need another reason to go? 24-hour hacker lounge. Register today! >>>> http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org_______________________________________________ >>>> Pyobjc-dev mailing list >>>> Pyo...@li... >>>> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev >>> >>> >>> ------------------------------------------------------------------------------ >>> Enter the BlackBerry Developer Challenge >>> This is your chance to win up to $100,000 in prizes! For a limited >>> time, >>> vendors submitting new applications to BlackBerry App World(TM) >>> will have >>> the opportunity to enter the BlackBerry Developer Challenge. See >>> full prize >>> details at: http://p.sf.net/sfu/Challenge >>> _______________________________________________ >>> Pyobjc-dev mailing list >>> Pyo...@li... >>> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev >> > |