sizeWithFont in MultiThread Crash!

Question

sizeWithFont crashed in multithread,this is the debug info:

1 0x00a0df8e in icu::RuleBasedBreakIterator::handleNext
2 0x00a0daff in icu::RuleBasedBreakIterator::next
3 0x00a0d174 in icu::RuleBasedBreakIterator::following
4 0x35879719 in WebCore::nextBreakablePosition
5 0x3587842a in -[NSString(WebStringDrawing) _web_drawInRect:withFont:ellipsis:alignment:lineSpacing:includeEmoji:measureOnly:]
6 0x35877da3 in -[NSString(WebStringDrawing) _web_sizeInRect:withFont:ellipsis:lineSpacing:]
7 0x3090d238 in -[NSString(UIStringDrawing) sizeWithFont:constrainedToSize:lineBreakMode:lineSpacing:]
8 0x3090cee3 in -[NSString(UIStringDrawing) sizeWithFont:constrainedToSize:lineBreakMode:]

now I solve the error by using a NSLock object,before using this function I will lock this object,and after that unlock it

but I think there must be a more better solution!

and I found this error only appeared when the NSString object for this function on both two threads are multi-lines text

Answer 1

• Formatting, please.

• "Solving" a multi-threaded problem by placing random locks around objects is never the right answer. Not ever. Multi-threading requires systemic design of your application.

• If a lock does "fix" the problem, showing what you locked and how is critical to assessing the situation.

• Some more symptoms would be helpful. Code, in particular. Code in your questions is very useful.

Given the lack of evidence, I'd wager that your are mutating a string on one thread while trying to grab the size on another. Or the object is being released on one thread while still using it another. Or you are manipulating an object from a secondary thread that isn't thread safe.

Answer 2

As a rule, you should not invoke UIKit methods [1] from a separate thread. It does not matter if you are taking locks, this is a non-starter.

When you are using multi-threaded applications, you need to make sure that any code that touches any UIKit objects executes on the main thread. This is achieved by using the performSelectorOnMainThread:withObject:waitUntilDone: method which invokes the given selector on the main thread:

http://developer.apple.com/iphone/library/documentation/cocoa/reference/foundation/Classes/NSObject_Class/Reference/Reference.html#//apple_ref/occ/instm/NSObject/performSelectorOnMainThread:withObject:waitUntilDone:

Or in MonoTouch: foo.InvokeOnMainThread (delegate { your_code_here });

[1] With iOS 4.0 the rule is relaxed for a handful of APIs.

Answer 3

I think performSelectorOnMainThread:withObject:waitUntilDone: is correct,

Before, I use a operation to calculate text size, And use waitUntilAllOperationsAreFinished in the main thread to wait for the operation's return,
But if I also use performSelectorOnMainThread:withObject:waitUntilDone in the operation, and set the waitUntilDone parameter to Yes(Because I need the result)
The main thread will be stucked

So now I remove waitUntilAllOperationsAreFinished ,and use a asynchronous object to ensure the operation won't start until the previous one stopped

                    [md removeAllObjects];
                    [md setObject:subString forKey:@"text"];
                    [md setObject:[NSNumber numberWithInt:view_w ] forKey:@"width"];
                    [md setObject:[NSNumber numberWithInt:height_left + font_h ] forKey:@"height"];
                    [self  performSelectorOnMainThread:
                     @selector(calculateTextRegion:)
                                            withObject:md
                                         waitUntilDone:YES];
                    CGSize stringSize = textRegion;