I'm using Mavericks and Google Chrome Version 34.0.1797.2 dev.
This is the error I receive:
Jan 25 17:09:12 genesis Google Chrome Helper[46267]: Process unable to create connection because the sandbox denied the right to lookup com.apple.coreservices.launchservicesd and so this process cannot talk to launchservicesd. : LSXPCClient.cp #426 `___ZN26LSClientToServerConnection21setupServerConnectionEiPK14__CFDictionary_block_invoke()` q=com.apple.main-thread
Jan 25 17:09:12 genesis Google Chrome Helper[46267]: Process unable to create connection because the sandbox denied the right to lookup com.apple.coreservices.launchservicesd and so this process cannot talk to launchservicesd.
Jan 25 17:09:12 genesis Google Chrome Helper[46267]: CGSLookupServerRootPort: Failed to look up the port for "com.apple.windowserver.active" (1100)
Any idea on what might be causing this? I've googled around and found no clue…
Best Answer
As you may know Google Chrome runs as a multi-process application. You have your initial "Google Chrome" process that manages the UI and plays "host" to a number of other processes. A new "renderer" process is created for each tab you open in Chrome, a "plugin" process for each extension you install, and there is a separate "GPU" process for the code that talks to the system's GPU. Each of these other processes appears in Activity Monitor as a "Google Chrome Helper" process.
To make Chrome more secure, the renderer processes run in a sandbox. They are only able to talk to the network through the host process and can only talk to specific files (for example, fonts and ColorSync profiles). They are also prevented from talking to other processes in the system, which is what causes these log messages. The renderer processes are trying to talk to the launchserviced and windowservice processes, but being prevented from doing that because of their sandbox.
This bug was resolved by a software engineer on Google's Chrome Security team with a commit in February 2014. Removing this one line of code resolved the problem.
[NSApplication sharedApplication];Amongst other things, calling the sharedApplication method opens a connection between an application and OS X's WindowServer, which you can see failing in the CGSLookupServerRootPort error.
The intention was for Chrome to call this method to "warm up" certain resources before enabling the sandbox; gaining access to certain files, processes or network resources before the sandbox restrictions fell in place. However it seems that at some point this attempt started failing, resulting in these errors in the log. My guess is that Apple considered this "warming up" an attempt to cheat the sandbox and started clamping down on it.
If I'm reading correctly this change reached the stable release channel with an update of Google Chrome to 34.0.1847.131 in April 2014.
Interestingly the Chrome team had been discussing removing these calls to the sharedApplication method back in October 2013 and even discussed removing Cocoa entirely from the renderer processes as a goal back in 2009.
On a related note, Apple released a security fix in April 2014 to resolve a bug where "WindowServer sessions could be created by sandboxed applications."