J'ai découvert comment déterminer la cause des freezes. Le truc est de prendre un échantillon du processus WindowServer du système lorsqu'il est gelé.
Évidemment, puisque je ne peux pas interagir avec le système lorsqu'il est gelé, j'ai utilisé un ordinateur séparé pour me connecter en ssh à mon mac, passer cette session au compte root avec sudo -s, puis exécuter la commande suivante au moment où le système se fige : sample WindowServer 5
Cela crée un échantillon qui montre ce que le serveur de fenêtres faisait bloqué pendant qu'il était gelé, et cela montre de manière constante qu'il était bloqué dans les fonctions suivantes :
4613 Fil_1658: Fil principal DispatchQueue_
+ 4613 démarrer (dans libdyld.dylib) + 1 [0x7fff71e563d5]
+ 4613 ??? (dans WindowServer) adresse de chargement 0x107900000 + 0x150d [0x10790150d]
+ 4613 SLXServer (dans SkyLight) + 1349 [0x7fff6b2b7af1]
+ 4613 boucle du serveur (dans SkyLight) + 602 [0x7fff6b2b7d52]
+ 2238 CGXRunOneServicesPass (dans SkyLight) + 731 [0x7fff6b2b6df9]
+ ! 2236 mach_msg (dans libsystem_kernel.dylib) + 60 [0x7fff71f8b76c]
+ ! : 2236 mach_msg_trap (dans libsystem_kernel.dylib) + 10 [0x7fff71f8b22a]
+ ! 2 mach_msg (dans libsystem_kernel.dylib) + 60,68 [0x7fff71f8b76c,0x7fff71f8b774]
+ 2087 CGXRunOneServicesPass (dans SkyLight) + 1761 [0x7fff6b2b71ff]
+ ! 2086 post_port_data (dans SkyLight) + 237 [0x7fff6b2b7551]
+ ! : 1986 rendezvousHandler(unsigned int, mach_msg_header_t*, void*) (dans SkyLight) + 29 [0x7fff6b138bd1]
+ ! : | 1984 CGXHandleMessage (dans SkyLight) + 101 [0x7fff6b2738bc]
+ ! : | + 1984 fonction d'invocation pour le bloc dans rendezvousHandler(unsigned int, mach_msg_header_t*, void*) (dans SkyLight) + 125 [0x7fff6b138c5f]
+ ! : | + 1979 _XGetEventShmem (dans SkyLight) + 310 [0x7fff6b0837bd]
+ ! : | + ! 1979 WSEventSourceCreateGraphShmemForAuditToken (dans SkyLight) + 82 [0x7fff6b1bccb5]
+ ! : | + ! 1978 WSAuditTokenCanMonitorEvents (dans SkyLight) + 171 [0x7fff6b2bab0d]
+ ! : | + ! : 1978 WSAuditTokenIsPostEventTCCApprovedCachingFailure (dans SkyLight) + 320 [0x7fff6b2ba977]
+ ! : | + ! : 1978 TCCAccessCheckAuditToken (dans TCC) + 269 [0x7fff6c788a9e]
+ ! : | + ! : 1978 TCCAccessRequest (dans TCC) + 345 [0x7fff6c783e5d]
+ ! : | + ! : 1978 _os_activity_initiate_impl (dans libsystem_trace.dylib) + 53 [0x7fff7206889c]
+ ! : | + ! : 1978 _dispatch_lane_barrier_sync_invoke_and_complete (dans libdispatch.dylib) + 60 [0x7fff71e15129]
+ ! : | + ! : 1978 _dispatch_client_callout (dans libdispatch.dylib) + 8 [0x7fff71e0963d]
+ ! : | + ! : 1978 __TCCAccessRequest_block_invoke.68 (dans TCC) + 862 [0x7fff6c784549]
+ ! : | + ! : 1978 tccd_send_message (dans TCC) + 656 [0x7fff6c784c25]
+ ! : | + ! : 1978 xpc_connection_send_message_with_reply_sync (dans libxpc.dylib) + 178 [0x7fff72088647]
+ ! : | + ! : 1978 dispatch_mach_send_with_result_and_wait_for_reply (dans libdispatch.dylib) + 50 [0x7fff71e1d882]
+ ! : | + ! : 1978 _dispatch_mach_send_and_wait_for_reply (dans libdispatch.dylib) + 609 [0x7fff71e1d3e7]
+ ! : | + ! : 1978 mach_msg (dans libsystem_kernel.dylib) + 60 [0x7fff71f8b76c]
+ ! : | + ! : 1978 mach_msg_trap (dans libsystem_kernel.dylib) + 10 [0x7fff71f8b22a]
Cela provient d'un échantillon qui a capturé deux secondes d'un freeze.
Cela montre clairement que TCC est le fautif. Maintenant que je le sais, la prochaine question est de trouver comment corriger les freezes.
