Re: CFRunLookFindMode crash
Re: CFRunLookFindMode crash
- Subject: Re: CFRunLookFindMode crash
- From: Martin Redington <email@hidden>
- Date: Wed, 15 Nov 2006 17:10:40 +0000
ok. I've posted SimpleThreadsCrashes.dmg at
http://www.mildmanneredindustries.com/downloads/SimpleThreadsCrash.dmg
This contains a modified version of Apple's SimpleThreads example. To
see the problem, run it, and hit the "Lots of Threads" button.
This will create a block of 200 threads, sleep for four seconds, (try
to) destroy the threads. It will try and run 10 such blocks. The
threads don't try to do anything. Wait a while, and it will crash.
Note that although large numbers of threads are required in the
example, to generate the Crash, in our app we can do this with just
two threads.
For best results, run it in the Debugger, as it will often take XCode
down if you just "run" it from XCode. Use Activity Monitor to observe
thread creation and destruction.
I've commented out lots of the original SimpleThreads code that isn't
used here.
As posted, SimpleThreadsCrashes uses the original SimpleThreads
method for thread shutdown. This is known to leak memory (see the
original comments in -[Controller killThreads:]), and does not kill
the threads, but should give you the __CFRunLookFindMode crash.
If you uncomment the SIMPLE_THREADS_FIX define in Controller.h, it
will try and use the fix to SimpleThreads suggested by John Nairn
(http://www.cocoabuilder.com/archive/message/cocoa/2002/8/23/51214).
This kills most of the threads, although a few will survive. It
usually crashes, but not in __CFRunLookFindMode, but somewhere else
during NSConnection setup.
Finally, if you comment out the ORIGINAL_RUN_LOOP define in
Controller.h, a slightly different strategy will be used to drive the
runLoop. A boolean shouldRun flag will be set on the TransferServer,
and as long as this is true, [[NSRunLoop currentRunLoop]
runMode:NSDefaultRunLoopMode beforeDate:newDate] will be called
repeatedly. When the shouldRun flag is set to NO, execution will fall
out of the loop, and the thread will stop.
This version appears to shutdown all of the worker threads, and
reliably produces the __CFRunLookFindMode crash.
Note that the crash reliably brings down Apple Mail as well for me,
and possibly other apps as well.
Any clues, hints, or suggestions for alternative approaches
gratefully received. I'm just about to open a new Radar bug on this
one ...
cheers,
Martin
On 14 Nov 2006, at 17:15, j o a r wrote:
On 14 nov 2006, at 17.53, Martin Redington wrote:
From the best I, and an Apple QA Engineer, could diagnose,
something was fiddling with the Core Foundation shared library
space. While I still have a sneaking suspicion that there is a
bug lurking around in there, the main problem that was causing my
issues was that Chax[1] was doing something nasty that it
shouldn't have been doing, and thus crashing Core Foundation, and
taking some of Apple's applications that were intimately tied to
CF at the time along with it (in my blog posting, Preview and
Mail.app)
That's interesting. My dev system is pretty stock, but I have seen
Mail.app go down quite a few times while I've been debugging. I
was already beginning to suspect some connection.
My suggestion: Before you do anything else, make absolutely sure
that you haven't got any system extensions, haxies, Input Managers
or other malware installed on your machine!
I can reliably replicate the issue (and another possible multi-
threading issue with NSUserDefaults that I posted about earlier).
Post the code and let others take a look.
j o a r
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden