Re: [Pyobjc-dev] stumped by a new round of NSBundle crashers

[Stuart H. <st...@ne...>]

> A crash at objc_msgSend usually means that you're sending a message to 
> a deallocated object.  NSZombieEnabled is your friend.  See TN2124 
> <http://developer.apple.com/technotes/tn2004/tn2124.html>.

Hi Bob,

Again thanks for the quick response. I should have mentioned that I 
have tried both with and without NSZombieEnabled. Also both with and 
without MallocStackLogging and friends. Still crashes in all cases. No 
reported zombies. Using *$r3 to guess the bad pointer and query 
malloc_history, reports nothing. No symbols available, since the crash 
is in Foundation/AppKit code. I know only a little bit about the 
register usage and stack layout, off to learn some more...

>
> Also, please clarify which version of PyObjC you're using.. and always 
> try the latest on svn trunk.  svn trunk generally has less bugs than 
> anything else.

I should also also have mentioned that the crashes happen with

	OS X 10.3.8
	pyobjc-1.3 *or* pyobjc -r1577
	MacPython-OSX-2.4.1-1

This is the same as my first go-round with the NSBundle hack. R1577 
fixed that problem, but not this new one.

> It might have something to do with the global NSAutoreleasePool that 
> PyObjC uses.  Depending on when and from which thread the PyObjC 
> plug-in is loaded, surprising behavior *might* happen.

The way I have been doing the test is loading a trivial plugin in the 
about box handler for my app. Use the app for a while (fine). Bring up 
the about box, crash within minutes. So, while the app is heavily 
multithreaded, all the PyObjC stuff is on the main thread. That said, I 
plan to use PyObjC on background threads, so I'll need to get my head 
around the appropriate idioms. I have been assuming I would initialize 
the plugin from the main thread before any worker threads need it.

Is it required to keep plugins around once their work is done, or 
somehow undo the NSBundle hack on the way out?

Thanks,
Stu