Re: [Pyobjc-dev] autorelease pool page corrupted

[Jake W. <del...@gm...>]

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

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