pyobjc-dev — CVS commit notices go here

Re: [Pyobjc-dev] the mysterious attribute error

[Burris T. E. <bu...@gi...>]

Another clue:

*** malloc[5538]: error for object 0x5b9f00: Double free

Somewhere, memory management is going awry.

burris

On Mar 27, 2004, at 11:24 PM, Ronald Oussoren wrote:

>
> On 28-mrt-04, at 4:11, Burris T. Ewell wrote:
>
>> Okay, I've removed all of the threads from my application.  It's  
>> completely kosher.  I use NSTasks for the workers, and DO for  
>> callbacks.  It works just fine most of the time.  When I click around  
>> between rows, especially when one or more rows are getting frequent  
>> updates, I get the weird crash with the disappearing attribute when  
>> the cell is redrawing.  A race condition that causes objects to get  
>> decref'd?
>
> From Subclassing NSCell at  
> http://developer.apple.com/documentation/Cocoa/Conceptual/ControlCell/ 
> index.html#//apple_ref/doc/uid/10000015i:
>
> <quote>
> If the subclass contains instance variables that hold pointers to  
> objects, consider overriding copyWithZone: to duplicate the objects.  
> The default version copies only pointers to the objects.
> </quote>
>
> You should implemented copyWithZone: unless you subclass has  
> '__slots__ = ()', otherwise the copy of a cell will share its __dict__  
> with the original, without updating the reference count. That will  
> give problems later on.
>
> Ronald
> --
> X|support bv            http://www.xsupport.nl/
> T:  +31 610271479       F:  +31 204416173
>

Re: [Pyobjc-dev] Best way to rectify attribute/method name conflation?

[Zachery B. <zb...@ur...>]

On Mar 28, 2004, at 10:14 AM, Zachery Bir wrote:

> def copyWithZone_(self, zone):
>     cell = super(IconAndTextCell, self).copyWithZone_(zone)
>     cell.setImage_(self.getImage())
>     return cell
>
> [snip]
>
> Am I right?

Apparently not:

 >>> from Foundation import *
 >>> from AppKit import *
 >>> cell = NSCell.alloc().init()
 >>> cell.image
<native-selector image of <NSCell: 0x372550>>
 >>> cell.image()
 >>> image = NSImage.alloc().init()
 >>> cell.setImage_(image)
 >>> cell.image
<native-selector image of <NSCell: 0x372550>>
 >>> cell.image()
NSImage 0x31d490 Size={0, 0} Reps=()
 >>>

So, I guess I needn't worry about the actual attribute version of 
'image' and I should use the second example above, and never worry 
about referencing the actual attribute. Ah, encapsulation :^)

Zac

[Pyobjc-dev] Re: [Pyobjc-checkins] CVS: pyobjc/Modules/objc objc_support.m,1.63,1.64

[Ronald O. <ous...@ci...>]

Hmm,

One of your GIL-related patches completely broke the mcfoo program, it 
now consistently deadlocks. On the bright side, this is a lot better 
than "crashes or deadlocks after a while, most of the time" :-).

What I don't understand is that the deadlock occurs due to a call to 
PyGILState_Ensure in thread 2, *at a location where that thread should 
already own the GIL*:

#0  0x90017048 in semaphore_wait_signal_trap ()
#1  0x9000e890 in _pthread_cond_wait ()
#2  0x95fd0324 in PyThread_acquire_lock ()
#3  0x95fa44f8 in PyEval_RestoreThread ()
#4  0x95fc63fc in PyGILState_Ensure ()
#5  0x004a004c in -[NSObject(PyObjCSupport) __pyobjc_PythonObject__] 
(self=0xa5f62728, _cmd=0x3a03) at Modules/objc/objc_support.m:57
#6  0x004a119c in pythonify_c_value (type=0x3903 "", datum=0xa5f6272c) 
at Modules/objc/objc_support.m:964
#7  0x004b3930 in ObjC_FFICaller (aMeth=0x164e750, self=0x164a350, 
args=0x40) at Modules/objc/libffi_support.m:1102
#8  0x004ad344 in objcsel_call (self=0x164e750, args=0x25c030) at 
Modules/objc/selector.m:575
#9  0x95f4a8d0 in PyObject_Call ()
#10 0x95fa9ba8 in PyEval_GetFuncDesc ()
#11 0x95fa9598 in PyEval_GetFuncDesc ()
#12 0x95fa6c64 in PyEval_EvalCode ()
#13 0x95fa7e30 in PyEval_EvalCodeEx ()
#14 0x95f5f354 in PyFunction_SetClosure ()
#15 0x95f4a8d0 in PyObject_Call ()
#16 0x004adac4 in pysel_call (self=0x164e750, args=0x0, kwargs=0x0) at 
Modules/objc/selector.m:1032
#17 0x95f4a8d0 in PyObject_Call ()
#18 0x95fa91ec in PyEval_CallObjectWithKeywords ()
#19 0x95fd39c0 in _PyObject_GC_Del ()
#20 0x900247e8 in _pthread_body ()

Ronald

P.S. I don't think it is necessary to call PyGILState_Ensure in 
__pyobjc_PythonObject__ (it should only be called when we own the GIL), 
but adding the call should be harmless.

[Pyobjc-dev] Best way to rectify attribute/method name conflation?

[Zachery B. <zb...@ur...>]

In ObjC, as you all know, method names and attributes can share names. 
In Python, they can't.

I'm trying to translate some code from ObjC to Python, and I'm having a 
hard time figuring out the proper way to untangle this mess.

I've got a class called IconAndTextCell, which derives from 
NSTextFieldCell (and thence from NSActionCell and NSCell - which is far 
enough back for this example). NSCell provides both an attribute image 
and a selector image(), and I'm trying to provide for the 
copyWithZone_() selector of my new class. Using an example in ObjC, I 
have this:

[orig ObjC]
- copyWithZone:(NSZone *)zone {
     ImageAndTextCell *cell = (ImageAndTextCell *)[super 
copyWithZone:zone];
     cell->image = [image retain];
     return cell;
}

the second statement there looks like it's going to be a pain in the 
backside to translate. The immediate thing that looked reasonable to me 
was to generate a new accessor (getImage) and do this:

def copyWithZone_(self, zone):
     cell = super(IconAndTextCell, self).copyWithZone_(zone)
     cell.image = self.getImage()
     return cell

Now, which 'image' attribute did I just clobber in the copied cell? The 
attribute or the accessor? Surely one or the other is already clobbered 
by the bridge, owing to the fact that Python won't allow two attributes 
with the same name.

So, even going the route of using NSCell's setImage_() mutator:

def copyWithZone_(self, zone):
     cell = super(IconAndTextCell, self).copyWithZone_(zone)
     cell.setImage_(self.getImage())
     return cell

doesn't seem like it will help, as the underlying data structure 
(NSCell.image) will get clobbered. Either NSCell will lose an attribute 
or an accessor.

Am I right?

Zac

Re: [Pyobjc-dev] the mysterious attribute error

[Burris T. E. <bu...@gi...>]

I tried putting in a __slots__ = ('controller',) but I still get a 
crash... :-(

burris

Re: [Pyobjc-dev] the mysterious attribute error

[Ronald O. <ous...@ci...>]

On 28-mrt-04, at 4:11, Burris T. Ewell wrote:

> Okay, I've removed all of the threads from my application.  It's  
> completely kosher.  I use NSTasks for the workers, and DO for  
> callbacks.  It works just fine most of the time.  When I click around  
> between rows, especially when one or more rows are getting frequent  
> updates, I get the weird crash with the disappearing attribute when  
> the cell is redrawing.  A race condition that causes objects to get  
> decref'd?

 From Subclassing NSCell at  
http://developer.apple.com/documentation/Cocoa/Conceptual/ControlCell/ 
index.html#//apple_ref/doc/uid/10000015i:

<quote>
If the subclass contains instance variables that hold pointers to  
objects, consider overriding copyWithZone: to duplicate the objects.  
The default version copies only pointers to the objects.
</quote>

You should implemented copyWithZone: unless you subclass has '__slots__  
= ()', otherwise the copy of a cell will share its __dict__ with the  
original, without updating the reference count. That will give problems  
later on.

Ronald
--
X|support bv            http://www.xsupport.nl/
T:  +31 610271479       F:  +31 204416173

[Pyobjc-dev] the mysterious attribute error

[Burris T. E. <bu...@gi...>]

Okay, I've removed all of the threads from my application.  It's 
completely kosher.  I use NSTasks for the workers, and DO for 
callbacks.  It works just fine most of the time.  When I click around 
between rows, especially when one or more rows are getting frequent 
updates, I get the weird crash with the disappearing attribute when the 
cell is redrawing.  A race condition that causes objects to get 
decref'd?

burris

Re: [Pyobjc-dev] Using NSURLConnection

[Bob I. <bo...@re...>]

On Mar 27, 2004, at 4:07 PM, David Remahl wrote:

> I've tried to use NSURLConnection to load a resource from a URL, but 
> very strange things happen when the framework tries to call my 
> delegate. This is some code from my project:
---
> I don't know what to do to make this work. Callbacks in general have 
> proven slightly shaky for me -- I think I have missed some critical 
> information.

Not sure why it isn't working for you, but these [attached files] are 
what I've used successfully.  If these don't work, upgrade to CVS HEAD 
of PyObjC.

-bob

[Pyobjc-dev] Using NSURLConnection

[David R. <da...@it...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I've tried to use NSURLConnection to load a resource from a URL, but 
very strange things happen when the framework tries to call my 
delegate. This is some code from my project:

     def startReadingFromURL( self, url ):
         self.waitingForDataFromURL = True
         nsurl = NSURL.URLWithString_(url)
         request = NSURLRequest.requestWithURL_(nsurl)
         connection = NSURLConnection.connectionWithRequest_delegate_( 
request, self )

     def connection_didReceiveData_(self, connection, data):
         print str(data)

When this runs, the program crashes just as it is supposed to call 
connection_didReceiveData_. The backtrace is a stack overflow due to 
recursion, and it looks like this:

0   libobjc.A.dylib          	0x90835cd0 -[Protocol 
descriptionForInstanceMethod:] + 0x10
1   com.apple.Foundation     	0x909fe5a0 
_NSMethodDescriptionForSelector + 0x84
2   com.apple.Foundation     	0x90a491e0 -[NSInvocationBuilder 
forward::] + 0x38
3   libobjc.A.dylib          	0x90836810 _objc_msgForward + 0xb0
4   com.apple.Foundation     	0x90a4db88 -[NSProxy respondsToSelector:] 
+ 0x50
5   _objc.so                 	0x002836c0 -[OC_PythonObject 
respondsToSelector:] + 0x40
6   com.apple.Foundation     	0x909fafec _NSDescriptionWithLocaleFunc + 
0x48
7   com.apple.CoreFoundation 	0x9019ed9c 
_CFStringAppendFormatAndArgumentsAux + 0xfdc
8   com.apple.CoreFoundation 	0x901a4b04 
_CFStringCreateWithFormatAndArgumentsAux + 0x90
9   com.apple.Foundation     	0x90a50bd4 +[NSException 
raise:format:arguments:] + 0x5c
10  com.apple.Foundation     	0x90a5cd5c +[NSException raise:format:] + 
0x2c
11  _objc.so                 	0x00283c08 -[OC_PythonObject 
forwardInvocation:] + 0x1e0
12  com.apple.Foundation     	0x90a4dbb0 -[NSProxy respondsToSelector:] 
+ 0x78
13  _objc.so                 	0x002836c0 -[OC_PythonObject 
respondsToSelector:] + 0x40
...
...
...
502 com.apple.Foundation     	0x909fafec _NSDescriptionWithLocaleFunc + 
0x48
503 com.apple.CoreFoundation 	0x9019ed9c 
_CFStringAppendFormatAndArgumentsAux + 0xfdc
504 com.apple.CoreFoundation 	0x901a4b04 
_CFStringCreateWithFormatAndArgumentsAux + 0x90
505 com.apple.Foundation     	0x90a50bd4 +[NSException 
raise:format:arguments:] + 0x5c
506 com.apple.Foundation     	0x90a5cd5c +[NSException raise:format:] + 
0x2c
507 _objc.so                 	0x00283c08 -[OC_PythonObject 
forwardInvocation:] + 0x1e0
508 com.apple.Foundation     	0x90a4dbb0 -[NSProxy respondsToSelector:] 
+ 0x78

I don't know what to do to make this work. Callbacks in general have 
proven slightly shaky for me -- I think I have missed some critical 
information.

/ Regards, David Remahl

- --- PGP key information---
pub  1024D/ 87256085 2003/06/12 David Remahl <da...@re...>
Web: http://ittpoi.com/david_remahl.asc
Fingerprint: 0C38 293C 86A9 7756 9CEA  4ED6 1651 620E 8725 6085
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (Darwin)

iD8DBQFAZe0jFlFiDoclYIURAt0EAJ9rVVsaI77ML0vmC6XWsIHBLVAB1ACeLPnk
rQazJlszNt+YyshoREiVr2k=
=R1Yk
-----END PGP SIGNATURE-----

Re: [Pyobjc-dev] DO is broken too

[Burris T. E. <bu...@gi...>]

I was using head but it was a week or two out of date.  Updating seems 
to have done the trick.  The demo app works.  Thank you!  I'm really 
psyched to use pyobjc.  There's no better way to write Mac software.

burris


On Mar 27, 2004, at 9:46 AM, Bob Ippolito wrote:

> On Mar 27, 2004, at 11:38 AM, Burris T. Ewell wrote:
>
>> I figured since I can't use pyobjc in multithreaded applications, 
>> I'll just use a subprocess and DO for communication.  I had tried DO 
>> for inter-thread communication before but it always crashed.  Anyway, 
>> DO is apparently broken in the general case.  The subprocess crashes 
>> when it tries to connect to the main application.  I tried messing 
>> around with a couple of python shells and either the client or the 
>> server always crashed, didn't work at all.
>>
>> http://gigagig.org/BT/doFoo.tgz
>
> Are you using CVS HEAD?  There were some very recent fixes for DO.
>
> -bob
>

Re: [Pyobjc-dev] DO is broken too

[Bob I. <bo...@re...>]

On Mar 27, 2004, at 11:38 AM, Burris T. Ewell wrote:

> I figured since I can't use pyobjc in multithreaded applications, I'll 
> just use a subprocess and DO for communication.  I had tried DO for 
> inter-thread communication before but it always crashed.  Anyway, DO 
> is apparently broken in the general case.  The subprocess crashes when 
> it tries to connect to the main application.  I tried messing around 
> with a couple of python shells and either the client or the server 
> always crashed, didn't work at all.
>
> http://gigagig.org/BT/doFoo.tgz

Are you using CVS HEAD?  There were some very recent fixes for DO.

-bob

[Pyobjc-dev] DO is broken too

[Burris T. E. <bu...@gi...>]

I figured since I can't use pyobjc in multithreaded applications, I'll 
just use a subprocess and DO for communication.  I had tried DO for 
inter-thread communication before but it always crashed.  Anyway, DO is 
apparently broken in the general case.  The subprocess crashes when it 
tries to connect to the main application.  I tried messing around with 
a couple of python shells and either the client or the server always 
crashed, didn't work at all.

http://gigagig.org/BT/doFoo.tgz


burris

Re: [Pyobjc-dev] crasher demo app

[Ronald O. <ous...@ci...>]

On 26-mrt-04, at 14:55, Bob Ippolito wrote:

>
> On Mar 26, 2004, at 1:54 AM, Ronald Oussoren wrote:
>
>>
>> On 26-mrt-04, at 0:03, Bob Ippolito wrote:
>>
>>>
>>> On Mar 25, 2004, at 4:23 PM, Ronald Oussoren wrote:
>>>
>>>>
>>>> On 25-mrt-04, at 22:08, Burris T. Ewell wrote:
>>>>
>>>>> First off, I appreciate all of the help here...
>>>>>
>>>>> On Mar 25, 2004, at 12:19 PM, Ronald Oussoren wrote:
>>>>>> If I remove those calls the application runs longer, e.g. it 
>>>>>> didn't crash yet :-)
>>>>>
>>>>> I don't think that's it...  I tried that, holding a reference to 
>>>>> the cell, and also retaining the application delegate that holds 
>>>>> references to the controller objects.  Still, inside the cell, the 
>>>>> controller attribute disappears inside drawInteriorWithFrame.  
>>>>> Here is a traceback from the full application, which is pretty 
>>>>> much the same as the demonstration.  This shouldn't be possible 
>>>>> since the cell sets self.controller inside of init() and nowhere 
>>>>> else is the attribute removed.
>>>>
>>>> Hmm, doesn't NSTableView use -copy? That might explain why 
>>>> self.controller disappears.
>>>>
>>>> There's definitly something fishy going on,
>>>
>>> There's fishy things with threads in PyObjC in general.. try this, 
>>> for example (I just ran into this bug today):
>>>
>>> http://undefined.org/~bob/PyURLProtocol_broken.tgz
>>>
>>> My guess is that it doesn't release the GIL when doing the call, so 
>>> when it gets the callback it can't acquire the GIL and deadlocks.
>>
>> Yup, we don't release the GIL when calling into Objective-C, and we 
>> get a callback on another thread here.
>>
>> This won't be completely solved before the 1.1 release, I'd prefer to 
>> get that out soon (we should have released that long ago). Doing a 
>> 90% solution should be possible by releasing the GIL when calling 
>> ffi_call (libffi_support.m).
>>
>> That won't solve the problems with mcfoo.
>
> I spent a few minutes playing with that, but it gets complicated 
> really fast and about 24 of the tests start crashing or deadlocking ;)

I noticed the crashing/deadlocking part :( and I wonder if these have 
anything to do with the problems we're seeing with mcfoo, to be honest 
I'm afraid they are related.

Just releaseing the GIL around calls to ffi_call is not too 
complicated, it adds less then 20 lines of code to libffi_support.m.  
More fine-grained releasing of the GIL will be a lot of work.

Ronald
>
> -bob
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> _______________________________________________
> Pyobjc-dev mailing list
> Pyo...@li...
> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev
>
>
--
X|support bv            http://www.xsupport.nl/
T:  +31 610271479       F:  +31 204416173

Re: [Pyobjc-dev] crasher demo app

[Bob I. <bo...@re...>]

On Mar 26, 2004, at 1:54 AM, Ronald Oussoren wrote:

>
> On 26-mrt-04, at 0:03, Bob Ippolito wrote:
>
>>
>> On Mar 25, 2004, at 4:23 PM, Ronald Oussoren wrote:
>>
>>>
>>> On 25-mrt-04, at 22:08, Burris T. Ewell wrote:
>>>
>>>> First off, I appreciate all of the help here...
>>>>
>>>> On Mar 25, 2004, at 12:19 PM, Ronald Oussoren wrote:
>>>>> If I remove those calls the application runs longer, e.g. it 
>>>>> didn't crash yet :-)
>>>>
>>>> I don't think that's it...  I tried that, holding a reference to 
>>>> the cell, and also retaining the application delegate that holds 
>>>> references to the controller objects.  Still, inside the cell, the 
>>>> controller attribute disappears inside drawInteriorWithFrame.  Here 
>>>> is a traceback from the full application, which is pretty much the 
>>>> same as the demonstration.  This shouldn't be possible since the 
>>>> cell sets self.controller inside of init() and nowhere else is the 
>>>> attribute removed.
>>>
>>> Hmm, doesn't NSTableView use -copy? That might explain why 
>>> self.controller disappears.
>>>
>>> There's definitly something fishy going on,
>>
>> There's fishy things with threads in PyObjC in general.. try this, 
>> for example (I just ran into this bug today):
>>
>> http://undefined.org/~bob/PyURLProtocol_broken.tgz
>>
>> My guess is that it doesn't release the GIL when doing the call, so 
>> when it gets the callback it can't acquire the GIL and deadlocks.
>
> Yup, we don't release the GIL when calling into Objective-C, and we 
> get a callback on another thread here.
>
> This won't be completely solved before the 1.1 release, I'd prefer to 
> get that out soon (we should have released that long ago). Doing a 90% 
> solution should be possible by releasing the GIL when calling ffi_call 
> (libffi_support.m).
>
> That won't solve the problems with mcfoo.

I spent a few minutes playing with that, but it gets complicated really 
fast and about 24 of the tests start crashing or deadlocking ;)

-bob

Re: [Pyobjc-dev] crasher demo app

[Ronald O. <ous...@ci...>]

On 26-mrt-04, at 0:03, Bob Ippolito wrote:

>
> On Mar 25, 2004, at 4:23 PM, Ronald Oussoren wrote:
>
>>
>> On 25-mrt-04, at 22:08, Burris T. Ewell wrote:
>>
>>> First off, I appreciate all of the help here...
>>>
>>> On Mar 25, 2004, at 12:19 PM, Ronald Oussoren wrote:
>>>> If I remove those calls the application runs longer, e.g. it didn't 
>>>> crash yet :-)
>>>
>>> I don't think that's it...  I tried that, holding a reference to the 
>>> cell, and also retaining the application delegate that holds 
>>> references to the controller objects.  Still, inside the cell, the 
>>> controller attribute disappears inside drawInteriorWithFrame.  Here 
>>> is a traceback from the full application, which is pretty much the 
>>> same as the demonstration.  This shouldn't be possible since the 
>>> cell sets self.controller inside of init() and nowhere else is the 
>>> attribute removed.
>>
>> Hmm, doesn't NSTableView use -copy? That might explain why 
>> self.controller disappears.
>>
>> There's definitly something fishy going on,
>
> There's fishy things with threads in PyObjC in general.. try this, for 
> example (I just ran into this bug today):
>
> http://undefined.org/~bob/PyURLProtocol_broken.tgz
>
> My guess is that it doesn't release the GIL when doing the call, so 
> when it gets the callback it can't acquire the GIL and deadlocks.

Yup, we don't release the GIL when calling into Objective-C, and we get 
a callback on another thread here.

This won't be completely solved before the 1.1 release, I'd prefer to 
get that out soon (we should have released that long ago). Doing a 90% 
solution should be possible by releasing the GIL when calling ffi_call 
(libffi_support.m).

That won't solve the problems with mcfoo.

Ronald
--
X|support bv            http://www.xsupport.nl/
T:  +31 610271479       F:  +31 204416173

Re: [Pyobjc-dev] crasher demo app

[Bob I. <bo...@re...>]

On Mar 25, 2004, at 4:23 PM, Ronald Oussoren wrote:

>
> On 25-mrt-04, at 22:08, Burris T. Ewell wrote:
>
>> First off, I appreciate all of the help here...
>>
>> On Mar 25, 2004, at 12:19 PM, Ronald Oussoren wrote:
>>> If I remove those calls the application runs longer, e.g. it didn't 
>>> crash yet :-)
>>
>> I don't think that's it...  I tried that, holding a reference to the 
>> cell, and also retaining the application delegate that holds 
>> references to the controller objects.  Still, inside the cell, the 
>> controller attribute disappears inside drawInteriorWithFrame.  Here 
>> is a traceback from the full application, which is pretty much the 
>> same as the demonstration.  This shouldn't be possible since the cell 
>> sets self.controller inside of init() and nowhere else is the 
>> attribute removed.
>
> Hmm, doesn't NSTableView use -copy? That might explain why 
> self.controller disappears.
>
> There's definitly something fishy going on,

There's fishy things with threads in PyObjC in general.. try this, for 
example (I just ran into this bug today):

http://undefined.org/~bob/PyURLProtocol_broken.tgz

My guess is that it doesn't release the GIL when doing the call, so 
when it gets the callback it can't acquire the GIL and deadlocks.

-bob

Re: [Pyobjc-dev] crasher demo app

[Burris T. E. <bu...@gi...>]

On Mar 25, 2004, at 1:23 PM, Ronald Oussoren wrote:
> Hmm, doesn't NSTableView use -copy? That might explain why 
> self.controller disappears.

Well, the code works for many iterations until the weirdness happens.  
If you do a check to make sure self hasattr controller, it will just 
crash a little bit later.  I think it's a memory smasher...  that's why 
we get different error codes and different things happening depending 
on the exact layout of the code we use.


burris

Re: [Pyobjc-dev] crasher demo app

[Ronald O. <ous...@ci...>]

On 25-mrt-04, at 22:08, Burris T. Ewell wrote:

> First off, I appreciate all of the help here...
>
> On Mar 25, 2004, at 12:19 PM, Ronald Oussoren wrote:
>> If I remove those calls the application runs longer, e.g. it didn't 
>> crash yet :-)
>
> I don't think that's it...  I tried that, holding a reference to the 
> cell, and also retaining the application delegate that holds 
> references to the controller objects.  Still, inside the cell, the 
> controller attribute disappears inside drawInteriorWithFrame.  Here is 
> a traceback from the full application, which is pretty much the same 
> as the demonstration.  This shouldn't be possible since the cell sets 
> self.controller inside of init() and nowhere else is the attribute 
> removed.

Hmm, doesn't NSTableView use -copy? That might explain why 
self.controller disappears.

There's definitly something fishy going on,

	Ronald

Re: [Pyobjc-dev] crasher demo app

[Burris T. E. <bu...@gi...>]

First off, I appreciate all of the help here...

On Mar 25, 2004, at 12:19 PM, Ronald Oussoren wrote:
> If I remove those calls the application runs longer, e.g. it didn't  
> crash yet :-)

I don't think that's it...  I tried that, holding a reference to the  
cell, and also retaining the application delegate that holds references  
to the controller objects.  Still, inside the cell, the controller  
attribute disappears inside drawInteriorWithFrame.  Here is a traceback  
from the full application, which is pretty much the same as the  
demonstration.  This shouldn't be possible since the cell sets  
self.controller inside of init() and nowhere else is the attribute  
removed.

Traceback (most recent call last):
   File  
"/tmp/BitTorrent.dst/Users/drue/Applications/BitTorrent.app/Contents/ 
Resources/__main__.py", line 16, in ?
     AppHelper.runEventLoop(argv=[])
   File  
"/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ 
python2.3/site-packages/PyObjC/PyObjCTools/AppHelper.py", line 50, in  
runEventLoop
     if not unexpectedErrorAlert():
   File  
"/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ 
python2.3/site-packages/PyObjC/PyObjCTools/AppHelper.py", line 31, in  
unexpectedErrorAlert
     "Continue", "Quit", None)
   File  
"/tmp/BitTorrent.dst/Users/drue/Applications/BitTorrent.app/Contents/ 
Resources/DLCell.py", line 34, in drawInteriorWithFrame_inView_
     self.controller.cview.unlockFocus()
AttributeError: 'DLCell' object has no attribute 'controller'
2004-03-25 13:02:35.697 BitTorrent[2148] An uncaught exception was  
raised
2004-03-25 13:02:35.698 BitTorrent[2148]  
/Users/drue/wa/PyBT/BitTorrent_med/main-embedded-interpreter.m:57  
pyobjc_main() PyRun_SimpleFile failed with file  
'/tmp/BitTorrent.dst/Users/drue/Applications/BitTorrent.app/Contents/ 
Resources/__main__.py'.  See console for errors.
2004-03-25 13:02:35.698 BitTorrent[2148] *** Uncaught exception:  
<NSInternalInconsistencyException>  
/Users/drue/wa/PyBT/BitTorrent_med/main-embedded-interpreter.m:57  
pyobjc_main() PyRun_SimpleFile failed with file  
'/tmp/BitTorrent.dst/Users/drue/Applications/BitTorrent.app/Contents/ 
Resources/__main__.py'.  See console for errors.


thanks,
burris

[Pyobjc-dev] libffi

[Thomas H. <th...@py...>]

[Crossposting both to the pyobjc and ctypes list]

Tom Tromey (afaik gcc developer) just posted a message about maintaining
and/or releasing libffi independently from gcc to the nearly dead libffi
list:

http://sources.redhat.com/ml/libffi-discuss/2004/msg00000.html

In the last paragraph he says:

  If you know someone who is interested in this discussion, by all means
  have them subscribe here and take part.  Ideally we'd get all the
  libffi users together to make decisions.  Until now we've pretty much
  made decisions unilaterally for libgcj's benefit, but we can and
  should change this to include anyone interested in the project.

I think this is of interest both for the ctypes and the pyobjc people,
if there are other parties you know it would be nice to tell them.

ctypes has already suffered from the sad state of libffi...

Thomas

Re: [Pyobjc-dev] crasher demo app

[Ronald O. <ous...@ci...>]

On 25-mrt-04, at 7:18, Burris T. Ewell wrote:

> Okay, here is a bare bones implementation of what I was describing.
>
> http://www.gigagig.org/BT/mcfoo.tgz
>
> Start this up.  It helps to click on the cells, try to drag them.  
> Sometimes it will hang.  Sometimes it will crash like this:
>
> *** malloc[1540]: Deallocation of a pointer not malloced: 0x726df0; 
> This could be a double free(), or free() called with the middle of an 
> allocated block; Try setting environment variable MallocHelp to see 
> tools to help debug
> *** malloc_zone_malloc[1540]: argument too large: 4294967292
>
> mcfoo has exited due to signal 10 (SIGBUS).
>

I noticed one odd thing in the source code class Worker.py contains:

class Worker (NibClassBuilder.AutoBaseClass):
     def init(self):
         self.cview = IBOutlet("cview")
         self.field = IBOutlet("field")
         self.progress = IBOutlet("progress")
         self.resized = 1
         NSBundle.loadNibNamed_owner_("cview", self)
         return self

The three calls to IBOutlet are bogus as the create a descriptor. Calls 
to IBOutlet should be at class level, and when you use AutoBaseClass 
you don't need them at all (as long as the outlets are defined in the 
NIB file).

If I remove those calls the application runs longer, e.g. it didn't 
crash yet :-)

Ronald

--
X|support bv            http://www.xsupport.nl/
T:  +31 610271479       F:  +31 204416173

Re: [Pyobjc-dev] crasher demo app

[Bob I. <bo...@re...>]

On Mar 25, 2004, at 1:33 PM, Bob Ippolito wrote:

>
> On Mar 25, 2004, at 12:09 PM, Bob Ippolito wrote:
>
>> On Mar 25, 2004, at 1:18 AM, Burris T. Ewell wrote:
>>
>>> Okay, here is a bare bones implementation of what I was describing.
>>>
>>> http://www.gigagig.org/BT/mcfoo.tgz
>>>
>>> Start this up.  It helps to click on the cells, try to drag them.  
>>> Sometimes it will hang.  Sometimes it will crash like this:
>>>
>>> *** malloc[1540]: Deallocation of a pointer not malloced: 0x726df0; 
>>> This could be a double free(), or free() called with the middle of 
>>> an allocated block; Try setting environment variable MallocHelp to 
>>> see tools to help debug
>>> *** malloc_zone_malloc[1540]: argument too large: 4294967292
>>>
>>> mcfoo has exited due to signal 10 (SIGBUS).
>>
>> Bill brought this to my attention off-list.  I haven't looked at your 
>> problem, however it's relatively safe to say that it's one of two 
>> things:
>>
>> (1) Reference counting.  Some of Cocoa doesn't retain things (like 
>> the table data source, I think).  So you will have to keep a 
>> reference to things like this somewhere on your own.  This sucks, 
>> most of us think it's a bug in Cocoa, and we have filed reports in 
>> radar.  If this does turn out to be your problem, I suggest filing a 
>> duplicate bug.
>
> Try retaining the cell, I did this, and it doesn't crash for me:
>
> class mcfooAppDelegate(NibClassBuilder.AutoBaseClass):
>     def init(self):
>         self.workers = []
>         self.cells = []
>         return self
>
>     def awakeFromNib(self):
>         cols = self.table.tableColumns()
>         cell = MyCell.alloc().init()
>         self.cells.append(cell)
>         cols[0].setDataCell_(cell)
>
> In any case, YMMV with Python threads.  Have fun debugging them :P

Never mind, it did crash.. eventually.

-bob

Re: [Pyobjc-dev] crasher demo app

[Bob I. <bo...@re...>]

On Mar 25, 2004, at 12:09 PM, Bob Ippolito wrote:

> On Mar 25, 2004, at 1:18 AM, Burris T. Ewell wrote:
>
>> Okay, here is a bare bones implementation of what I was describing.
>>
>> http://www.gigagig.org/BT/mcfoo.tgz
>>
>> Start this up.  It helps to click on the cells, try to drag them.  
>> Sometimes it will hang.  Sometimes it will crash like this:
>>
>> *** malloc[1540]: Deallocation of a pointer not malloced: 0x726df0; 
>> This could be a double free(), or free() called with the middle of an 
>> allocated block; Try setting environment variable MallocHelp to see 
>> tools to help debug
>> *** malloc_zone_malloc[1540]: argument too large: 4294967292
>>
>> mcfoo has exited due to signal 10 (SIGBUS).
>
> Bill brought this to my attention off-list.  I haven't looked at your 
> problem, however it's relatively safe to say that it's one of two 
> things:
>
> (1) Reference counting.  Some of Cocoa doesn't retain things (like the 
> table data source, I think).  So you will have to keep a reference to 
> things like this somewhere on your own.  This sucks, most of us think 
> it's a bug in Cocoa, and we have filed reports in radar.  If this does 
> turn out to be your problem, I suggest filing a duplicate bug.

Try retaining the cell, I did this, and it doesn't crash for me:

class mcfooAppDelegate(NibClassBuilder.AutoBaseClass):
     def init(self):
         self.workers = []
         self.cells = []
         return self

     def awakeFromNib(self):
         cols = self.table.tableColumns()
         cell = MyCell.alloc().init()
         self.cells.append(cell)
         cols[0].setDataCell_(cell)

In any case, YMMV with Python threads.  Have fun debugging them :P

-bob

Re: [Pyobjc-dev] crasher demo app

[Just v. R. <ju...@le...>]

Bob Ippolito wrote:

> P.S.:  Please don't say "but I really do want to use threads".  Trust 
> me, you don't. 

Bob, you're being needlessly patronizing. Threading with PyObjC, if used
correctly, _should_ work. Whether or not it's the right or the best
solution to the problem is not for us to decide. Maybe he has blocking C
calls to deal with? I don't know, don't care even.

I've very briefly looked at the example code, and I don't immediately
see anything obviously wrong. It seems totally possible we're looking at
a PyObjC bug.

Just

Re: [Pyobjc-dev] crasher demo app

[Bob I. <bo...@re...>]

On Mar 25, 2004, at 1:18 AM, Burris T. Ewell wrote:

> Okay, here is a bare bones implementation of what I was describing.
>
> http://www.gigagig.org/BT/mcfoo.tgz
>
> Start this up.  It helps to click on the cells, try to drag them.  
> Sometimes it will hang.  Sometimes it will crash like this:
>
> *** malloc[1540]: Deallocation of a pointer not malloced: 0x726df0; 
> This could be a double free(), or free() called with the middle of an 
> allocated block; Try setting environment variable MallocHelp to see 
> tools to help debug
> *** malloc_zone_malloc[1540]: argument too large: 4294967292
>
> mcfoo has exited due to signal 10 (SIGBUS).

Bill brought this to my attention off-list.  I haven't looked at your 
problem, however it's relatively safe to say that it's one of two 
things:

(1) Reference counting.  Some of Cocoa doesn't retain things (like the 
table data source, I think).  So you will have to keep a reference to 
things like this somewhere on your own.  This sucks, most of us think 
it's a bug in Cocoa, and we have filed reports in radar.  If this does 
turn out to be your problem, I suggest filing a duplicate bug.

(2) Multithreading.  Multithreading, especially in Python, is just not 
the right solution.  Even without Python, Cocoa is not re-entrant, and 
the recommended way to communicate between threads in Objective C is 
via DO (or some similar safe indirection).  You might as well just use 
processes.  They aren't as expensive as they used to be (a process is a 
mach thread with its own copy-on-write memory space), they prevent you 
from making stupid near-impossible-to-debug bugs because each one plays 
in its own memory sandbox, and you can end up scaling your application 
to multiple machines when/if you ever need to.

	(2b) Instead of using multiple proceses, it's possible to use 
Stackless Python, where you can get the things you want from threads 
(writing blocking-style code that is "asynchronous") without the evil 
things that pre-emptive threads bring to the table because you do your 
own scheduling.  I'm not sure if I should recommend this approach right 
now though.  The Stackless CVS is somewhat volatile because we just had 
a sprint, you currently need to know what you're doing in order to use 
it effectively, and there isn't much in the way of documentation -- 
especially when interacting with Cocoa.  All of these things will be 
solved, just not this week :)

If the problem is related to multithreading, I'd like to help you 
refactor it into either multiprocess or stackless, but I can't offer 
much assistance until next week at the earliest.  And hey, if you're 
lucky, this crash might pique Ronald's interest, and he might find and 
fix this bug before I get a chance to even look at it ;)

-bob

P.S.:  Please don't say "but I really do want to use threads".  Trust 
me, you don't.  Even Guido recommends the multi-process model (as per 
his keynote this morning), because the GIL is just too hard to get rid 
of without killing performance and/or overcomplicating the 
interpreter's implementation, and he doesn't want to adopt the 
"separate object space" sort of thread model (the sane kind, that 
actually works in practice).