Reputation: 24767
The crash happens in the following code:
void CocoaCommRequest::launchSync()
{
launchAsync();
while (![_delegate finished])
{
[[NSRunLoop currentRunLoop] runMode:NSDefaultRunLoopMode beforeDate:[NSDate distantFuture]];
}
}
The crash stack is (partial):
Exception Type: SIGSEGV
Exception Codes: SEGV_ACCERR at 0x8
Crashed Thread: 0
Thread 0 Crashed:
0 0x3aa9b5d0 objc_msgSend + 15
1 0x32d7a8f7 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 15
2 0x32d7a15d __CFRunLoopDoSources0 + 213
3 0x32d78f2f __CFRunLoopRun + 647
4 0x32cec23d CFRunLoopRunSpecific + 356
5 0x32cec0c9 CFRunLoopRunInMode + 104
6 0x336105c3 -[NSRunLoop(NSRunLoop) runMode:beforeDate:] + 255
7 0x000978f9 CocoaCommRequest::launchSync() (CocoaCommRequest.mm:46)
I could not reproduce it locally, but only in production. What could make this code crash? Could it be some kind of memory issue?
Upvotes: 0
Views: 2444
Reputation: 689
I don't know what happens in launchAsync();
and before launchSync()
, but if you perform those operations in another threads, you could get crash or unexpected behavior because NSRunLoop is not thread safe. There are from [Thread Safety and Run Loop Objects] of Apple doc.1:
The functions in Core Foundation are generally thread-safe and can be called from any thread. If you are performing operations that alter the configuration of the run loop, however, it is still good practice to do so from the thread that owns the run loop whenever possible.
The Cocoa NSRunLoop class is not as inherently thread safe as its Core Foundation counterpart. If you are using the NSRunLoop class to modify your run loop, you should do so only from the same thread that owns that run loop. Adding an input source or timer to a run loop belonging to a different thread could cause your code to crash or behave in an unexpected way.
Upvotes: 4