Re: CFRunLoopFindMode crash (was CFRunLookFindMode crash)
Re: CFRunLoopFindMode crash (was CFRunLookFindMode crash)
- Subject: Re: CFRunLoopFindMode crash (was CFRunLookFindMode crash)
- From: Martin Redington <email@hidden>
- Date: Thu, 16 Nov 2006 05:03:31 +0000
Having filed my Radar bug (4838357), I'm just soak testing a
workaround in my app which tries to avoid the situation where the
crash occurs.
In the meantime, I booted up an old PowerPC box, to try and replicate
the error there.
Sure enough, I get an identical error on PowerPC (my main box, and
previous results were on intel). I tried using the debug frameworks,
but the SimpleThreads variant wouldn't run, due to a font issue
unrelated to this bug. An alternative, command line based test
program (that I can't post because it contains proprietary code) did
run with the debug frameworks.
A screenshot of the debugger, with crash is at http://
www.mildmanneredindustries.com/graphics/CFRunLoopFindModePPC.png
I couldn't work out how to tell XCode/GDB where to find the source
for CFRunLoop, but in CF-268.27, line 371 is as shown below:
/* call with rl locked */
static CFRunLoopModeRef __CFRunLoopFindMode(CFRunLoopRef rl,
CFStringRef modeName, Boolean create) {
CFRunLoopModeRef rlm;
struct __CFRunLoopMode srlm;
srlm._base._isa = __CFISAForTypeID(__kCFRunLoopModeTypeID);
srlm._base._info = 0;
_CFRuntimeSetInstanceTypeID(&srlm, __kCFRunLoopModeTypeID); //
Line 371
srlm._name = modeName;
and _CFRuntimeSetInstanceTypeID is pretty trivial:
void _CFRuntimeSetInstanceTypeID(CFTypeRef cf, CFTypeID typeID) {
__CFBitfieldSetValue(((CFRuntimeBase *)cf)->_info, 15, 8, typeID);
}
One other thing that seems worth noting. In the test program, the
crash occurs quite late on in the sequence of blocks. Richard Low
reports a similar sounding, DO related issue at http://
www.wentnet.com/misc/nsproxy.html, where the crash always occurred at
a certain point in the program (although I'm not certain that this
was in CFRunLoopFindMode).
It almost sounds as though some of counter issue, although I'm not
sure how that relates to the code where the problem appears to be
located.
On 15 Nov 2006, at 18:36, Martin Redington wrote:
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:
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