On 4 Mar 2011, at 18:24, Banlu Kemiyatorn wrote: > On Sat, Mar 5, 2011 at 1:03 AM, Richard Frith-Macdonald > <[email protected]> wrote: > > Thanks! I switched to GNUstep objc runtime now and the problem is > gone. Thank you Richard and David. > >> I suspect that what you have run into here is a bug in the gnu Objective-C >> runtime. >> >> You have two threads started and immediately calling NSLog, which in turn >> immediately tries to access the user defaults system. >> The user defaults system is protected by a lock 'classLock' created in its >> +initialize method, which is run automatically by the runtime. >> The +initialize method is supposed to run in a thread-safe manner *before* >> any other method in the class can run ... so this should mean that >> classLock, created in +initialize, can safely be used later. >> >> What I think is happening is that one thread calls the +standarduserDefault >> method, and the runtime calls +initialize, then before +initialize has >> completed, the second thread calls +standardUserDefaults (and the runtime >> incorrectly lets it), which tries to lock classLock before it has been >> created. This will send a _lock method to a nil object, which does nothing. >> The thread then creates the shared user defaults object and tries to unlock >> classLock, but by this time the first thread has created the lock, so an >> -unlock message is sent to classLock when in has not been locked. >> >> This bug only rarely manifests, since it depends on a race condition when a >> class is initialized, and in most non-trivial programs, most important >> classes are used before any threads are started. You could check to see if >> this is your problem by calling any NSUserDefaults method before starting >> the threads... if it is, doing that will prevent the exception from >> occurring. >> >> Unless it's been fixed, this is probably the biggest outstanding bug in the >> gnu runtime.
I added a configure-time check in gnustep-base to detect objc runtime libraries which don't support +initialise properly and warn about them. I also added a run-time alert to be printed if a program becomes multithreaded and configure had detected that the runtime library was not thread safe. _______________________________________________ Gnustep-dev mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnustep-dev
