Re: [Pyobjc-dev] Memory management bug using .new() -- and another one?
Brought to you by:
ronaldoussoren
Menu
▾
▴
Re: [Pyobjc-dev] Memory management bug using .new() -- and another one?
|
From: Ronald O. <ron...@ma...> - 2009-07-08 11:14:36
|
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 |
