Re: [Pyobjc-dev] stumped by a new round of NSBundle crashers
Brought to you by:
ronaldoussoren
From: Bob I. <bo...@re...> - 2005-04-10 22:09:58
|
On Apr 10, 2005, at 2:52 PM, Stuart Halloway wrote: >> 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>. > > 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. NSZombieEnabled probably doesn't apply to raw CoreFoundation stuff, which is probably happening here. Without a runnable test case, I can only make wild guesses. >> 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. It sounds like this is a bad time to load plugins, probably due to the global NSAutoreleasePool. The global NSAutoreleasePool was never really that good of an idea (theoretically) in the first place, but it's necessary (practically) in order to play around with PyObjC easily from an interactive interpreter that is not NSRunLoop based. I'll add a function to the objc module that lets you throw away that NSAutoreleasePool explicitly. I'm in the middle of refactoring objc.inject, but I should (hopefully) be able to finish both today. > Is it required to keep plugins around once their work is done, or > somehow undo the NSBundle hack on the way out? The Objective-C runtime in current versions of Mac OS X does not allow for unloading (enforced by dyld).. you couldn't get rid of a plugin if you tried. The NSBundle hack is perfectly safe (or now it is, anyway). There is no reason to want to remove it. It is smart enough to only install itself if the implementation of NSBundle doesn't support what it needs to support. This means that it will never install itself more than once, and it won't install itself at all if the implementation of NSBundle in some future version of Foundation implements the feature it's looking for. You did find an edge case that we didn't test, looking up a non-existent class. That is now fixed, and I'm now quite sure that there are zero bugs left in what it does. -bob |