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: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
>>
>
|
