Invoking the es_delete_client causes intermittent crashes.
I called es_delete_client in thread 1. By the way, a crash is occurring at thread 0. Is there a way to find out the cause?
Intermittent crash occurs when calling es_delete_client.
Exception Type: EXC_CRASH (SIGKILL)
This indicates that your process was most likely killed from the outside. That explains why the crashing thread is 0: Signals sent from outside your process are targeted at the process itself (rather than a specific thread) and, while it’s unspecified what thread the signal will be delivered to [1], in practice it’s usually the main thread.
The most likely cause of this is that your ES client is unresponsive.
Thread 2:: Dispatch queue: BBReaderQueue
0 libsystem_kernel.dylib … __ulock_wait + 8
1 libsystem_platform.dylib … _os_unfair_lock_lock_slow + 228
2 libobjc.A.dylib … objc_sync_enter + 36
3 com.ahnlab.V3FltES … -[V3FltESContext ReferenceIncrease] + 36 …
4 com.ahnlab.V3FltES … -[V3FltESContext FilteringAbout:] + 40 …
5 com.ahnlab.V3FltES … __33-[V3FltESContext InitializeWith:]_block_invoke + 176 …
6 libEndpointSecurity.dylib … BBReader<ESMessageReaderConfig>::handleItems() + 292
What’s going on here? This looks like your ES client event handling block is stuck in an @synchronize. That’s bad for two reasons:
-
@synchronizeis not a great idea for performance-critical work like this. Switch to an explicitos_unfair_lock. -
Why is it stuck? ES expects your event handling block to be responsive even if you are in the process of tearing down the ES client.
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"
[1] I wrote a doc about this a long time ago (QA1184 Signals and Threads). I haven’t looked to see if the algorithm has changed since then.