Fwd: CFRunLookFindMode crash
Fwd: CFRunLookFindMode crash
- Subject: Fwd: CFRunLookFindMode crash
- From: Martin Redington <email@hidden>
- Date: Wed, 15 Nov 2006 18:36:43 +0000
I just noticed that in the code I posted, both the
ORIGINAL_RUN_LOOP
SIMPLE_THREADS_FIX
defines are uncommented. Comment out the SIMPLE_THREADS_FIX in
Controller.h to get the behaviour of the original Apple SimpleThreads
code.
Begin forwarded message:
From: Martin Redington <email@hidden>
Date: 15 November 2006 17:10:40 GMT
To: Cocoa-Dev Mail <email@hidden>
Cc: j o a r <email@hidden>
Subject: Re: CFRunLookFindMode crash
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:
40ucl.ac.uk
This email sent to email@hidden
_______________________________________________
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