Re: [Pyobjc-dev] autorelease pool page corrupted

[Ronald O. <ron...@ma...>]

On 21 Nov 2013, at 13:37, Jake Wang <del...@gm...> wrote:

> Thank you Ronald,
> 
> I didn't use Objective-C before, and only in a recent project, I realised that some functions were required to use some Objc code, then I found PyObjc is a great option. Sorry for the stupid question I posted :)

It is not a stupid question at al!  The answer is only obvious if you know how memory management in Objective-C actually works, which is different from Python’s and furthermore PyObjC tries hard to hide most of the memory management from Python programmers but that abstraction layer cannot hide everything (I wish it could…)

Ronald

> 
> Anyway, with Diez's and your help, the issue I encountered was resolved, and I learned it about the NSAutoreleasePool.
> 
> Thanks again!
> Jake
> 
> 
> On Thu, Nov 21, 2013 at 7:34 PM, Ronald Oussoren <ron...@ma...> wrote:
> 
> On 03 Nov 2013, at 12:14, Diez B. Roggisch <de...@we...> wrote:
> 
>> Hi,
>> 
>> the problem is obvious: you allocate the pool from within the *MAIN* thread, not within the run-method of your EventHandlingThread. Thus it's essentially useless.
> 
> That’s obvious if you already know Objective-C :-).     For the records (and something that I should somehow include in PyObjC’s documentation): an NSAutoreleasePool is a fairly magic object that has a global effect for a single thread. You must allocate a pool on every thread that uses Cocoa, and if you create two nested pools like so:
> 
>       p1 = NSAutoreleasePool.alloc().init()
>       p2 = NSAutoreleasePool.alloc().init()
> 
> Then draining (clearing) p1 will also drain p2. That is,  NSAutoreleasePool objects can (more or less) be seen as markers in a per-thread stack of objects and draining a pool calls “release” on all objects on the stack upto that marker.
> 
> For the most part you don’t have to worry about this, as long as you create an regularly drain an autorelease pool on every thread (and you don’t even have to do the draining bit if you use a Cocoa event loop in the thread)
> 
> Ronald
>  
>> 
>> Diez
>> 
>> On Oct 29, 2013, at 3:03 AM, Jake Wang <del...@gm...> wrote:
>> 
>>> Hi Diez,
>>> 
>>> Thanks for your sample code, which is really helpful.
>>> 
>>> Please find my sample code as attached.
>>> 
>>> Entrance script: test_wx_and_event_2.py
>>> 
>>> Thread 1 - the main thread
>>> Thread 2 - user_event.EventHandlingThread
>>> 
>>> It is slightly different, because only the first thread (the main thread) has PyObjc code, the second thread just shares an event queue with the first thread.
>>> 
>>> After I added auto release code in the second thread, I got a new error:
>>> 
>>> objc[1488]: Object 0x10791bf50 of class __NSCFString autoreleased with no pool in place - just leaking - break on objc_autoreleaseNoPool() to debug
>>> 
>>> Also got the system error when quitting the app.
>>> 
>>> Thanks,
>>> Jake
>>> 
>>> 
>>> On Sun, Oct 27, 2013 at 2:45 PM, Diez B. Roggisch <de...@we...> wrote:
>>> 
>>> 
>>> On Oct 27, 2013, at 3:35 AM, Jake Wang <del...@gm...> wrote:
>>> 
>>>> Hi Diez,
>>>> 
>>>> Thanks for your reply and links, I tried some auto release code in the sample code (https://github.com/jiakuan/wx-sample), but still no luck.
>>> 
>>> I don't see it, can you show it to me?
>>> 
>>> 
>>>> 
>>>> I tried to replace the following code:
>>>> 
>>>> def OnUnexpectedExit(event):
>>>>     #
>>>>     # Event handler that deals with the unexpected close event.
>>>>     #
>>>>     wx.GetApp().ExitMainLoop()
>>>> 
>>>> to this:
>>>> 
>>>> def OnUnexpectedExit(self, event):
>>>>     #
>>>>     # Event handler that deals with the unexpected close event.
>>>>     #
>>>>         sys.exit()
>>>> 
>>>> Then no such error any more. I guess the issue was related to wxPython with PyObjc in some way.
>>> 
>>> I'm not sure if that's a good solution. There are a *lot* of possibilities here, and under normal circumstances, whatever you do in a user-space program shouldn't cause problems for the OS. However, the rather "rude" way of terminating a program you chose here might have just push the problem from your logging output to the system log's output, because some application cleanup hasn't been performed. This is just guessing, but a check couldn't hurt.
>>> 
>>> What you *must* verify though is that the lack of autorelease-pool doesn't introduce garbage over time.
>>> 
>>> I created the attached program to simulate that. You can ignore most of it of course, but if you put a call to "garbage_producer" with e.g. a million bytes as argument into your event handler, you should be able to see in the activity monitor if the process grows in size.
>>> 
>>> If so, you have to use a pool.
>>> 
>>> 
>>>> 
>>>> The reason why we choose PyObjc and wxPython is that we want to use Python language to share the majority of business logic on both Mac OS X and Windows. The platform-dependent requirement is a relative small part, which only contains global events listening, and a system tray icon (this code can be shared on both Mac and Windows too).
>>>> 
>>>> Any better solutions?
>>> 
>>> Better is relative. I personally would *never* go with wx, as it's not good in looks as well as API. If being cross-platform was justified for me enough (meaning the UI was sophisticated enough so that developing it natively would be a major effort), I'd be using Qt, and one of it's available bindings.
>>> 
>>> Of course, these are matters of taste. I just suggest exploring the alternatives.
>>> 
>>> Diez
>>> 
>>> 
>>> <wx-sample.zip>------------------------------------------------------------------------------
>>> Android is increasing in popularity, but the open development platform that
>>> developers love is also attractive to malware creators. Download this white
>>> paper to learn more about secure code signing practices that can help keep
>>> Android apps secure.
>>> http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk_______________________________________________
>>> Pyobjc-dev mailing list
>>> Pyo...@li...
>>> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev
>> 
>> ------------------------------------------------------------------------------
>> Android is increasing in popularity, but the open development platform that
>> developers love is also attractive to malware creators. Download this white
>> paper to learn more about secure code signing practices that can help keep
>> Android apps secure.
>> http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk_______________________________________________
>> Pyobjc-dev mailing list
>> Pyo...@li...
>> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev
> 
>