Re: CFRunLookFindMode crash
Re: CFRunLookFindMode crash
- Subject: Re: CFRunLookFindMode crash
- From: Martin Redington <email@hidden>
- Date: Thu, 16 Nov 2006 14:53:49 +0000
I'm sure it does *seem* to work fine - my "modern" threading code
looks almost exactly like this (http://developer.apple.com/
documentation/Cocoa/Conceptual/Multithreading/articles/
CocoaDOComm.html provides a model for this). This is pretty much
identical to the code I posted, if the ORIGINAL_RUN_LOOP define is
commented out.
In my application, in normal conditions, extrapolating from some test
cases, it would take 50 hours for the user to hit this issue, based
on a new (shortlived) thread being created every five minutes.
Unfortunately, this is a real use case for the app. It takes a lot
less time if you have more than one worker thread running
simultaneously - this seems to flush the issue out of the woodwork.
If you're just creating a few worker threads, one at a time, or even
quite a few worker threads, you probably won't have seen the issue -
we have thousands of users using the current version of the app, and
although I suspect some of them are hitting the issue, we only really
got a clear handle on when we introduced a polling method, which
creates a new thread every five minutes.
cheers,
Martin
On 16 Nov 2006, at 09:30, Nir Soffer wrote:
I'm using this method to terminate a DO thread. Seems to work fine.
To terminate a thread, the client call [server terminate] over DO,
which will cause the server to call [client setServer:nil] over DO
and release the server proxy before the server thread exit.
//// Server Class
+ (void)connectWithPorts:(NSArray *)portArray
{
NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];
Server *instance = [[self alloc] init];
NSConnection *connection =
[[NSConnection alloc] initWithReceivePort:[portArray
objectAtIndex:0]
sendPort:[portArray
objectAtIndex:1]];
[connection setRootObject:instance];
// Connect with the client
[(id <Client>)[connection rootProxy] setServer:instance];
// Run until termination
do {
[[NSRunLoop currentRunLoop] runMode:NSDefaultRunLoopMode
beforeDate:[NSDate distantFuture]];
} while ([instance isRunning]);
// Disconnect from the client. If we don't do this, instnace is
// never released!
[(id <Client>)[connection rootProxy] setServer:nil];
[connection release];
[instance release];
[pool release];
}
- (void)terminate
{
running = NO;
}
- (BOOL)isRunning
{
return running;
}
//// Client Class
- (void)setServer:(id)anObject
{
[anObject retain];
[anObject setProtocolForProxy:@protocol(Server)];
[server release];
server = (id <Server>)anObject;
}
On 15/11/2006, at 19:10, Martin Redington wrote:
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
Best Regards,
Nir Soffer
_______________________________________________
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