Como sabrás, Google Chrome se ejecuta como una aplicación multiproceso . Tienes tu proceso inicial "Google Chrome" que gestiona la interfaz de usuario y hace de "anfitrión" de otros procesos. Se crea un nuevo proceso "renderizador" para cada pestaña que se abre en Chrome, un proceso "plugin" para cada extensión que se instala, y hay un proceso "GPU" separado para el código que habla con la GPU del sistema. Cada uno de estos procesos aparece en el Monitor de Actividad como un proceso "Google Chrome Helper".
Para que Chrome sea más seguro, los procesos del renderizador se ejecutan en un caja de arena . Sólo pueden hablar con la red a través del proceso anfitrión y sólo pueden hablar con archivos específicos (por ejemplo, fuentes y perfiles ColorSync). También se les impide hablar con otros procesos en el sistema, que es lo que causa estos mensajes de registro. Los procesos de renderización están intentando hablar con los procesos launchserviced y windowservice, pero se les impide hacerlo debido a su caja de arena.
Este fallo fue resuelto por un ingeniero de software del equipo de seguridad de Chrome de Google con un comprometerse en febrero de 2014. La eliminación de esta línea de código resolvió el problema.
[NSApplication sharedApplication];
Entre otras cosas, al llamar al método sharedApplication se abre una conexión entre una aplicación y el WindowServer de OS X, que puedes ver que falla en el error CGSLookupServerRootPort.
La intención era que Chrome llamara a este método para "calentar" ciertos recursos antes de habilitar la caja de arena; obtener acceso a ciertos archivos, procesos o recursos de red antes de que las restricciones de la caja de arena entraran en vigor. Sin embargo, parece que en algún momento este intento empezó a fallar, dando lugar a estos errores en el registro. Mi opinión es que Apple consideró este "calentamiento" como un intento de engañar al sandbox y empezó a tomar medidas drásticas al respecto.
Si estoy leyendo correctamente este cambio llegó al canal de liberación estable con un actualización de Google Chrome a 34.0.1847.131 en abril de 2014.
Curiosamente, el equipo de Chrome había estado discutiendo eliminando estas llamadas al método sharedApplication en octubre de 2013 e incluso se habló de eliminar por completo Cocoa de los procesos de renderización como objetivo en 2009.
En una nota relacionada, Apple ha publicado una corrección de seguridad en abril de 2014 para resolver un fallo por el que "las sesiones de WindowServer podían ser creadas por aplicaciones en sandbox".
