10

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...

Improve this question
5
  • 1
    I see that log message primarily in conjunction with this problem: discussions.apple.com/message/23755770#23755770 (Mavericks 'runs out' of TCP sockets.)
    – Benjamin Riggs
    Feb 25, 2014 at 5:32
  • 1
    The first two are trivial to explain - the sandbox is logging denials so google developers can fix that code as the OS is denying an access that the code asked for. The last message might be need someone to look at chrome source code. What problem do these cause? Can you make the messages appear on command?
    – bmike ♦
    Mar 10, 2014 at 13:53
  • I'm not sure if I can trigger them. I just don't like too many error/warning messages in my logs.
    – Paweł Gościcki
    Mar 11, 2014 at 9:36
  • 1
    If you don't like warning messages in your logs, you simply shouldn't run "dev" versions of software. In Chrome's case this means that the software is not meant for general release, and that it most likely contains bugs and perhaps warning messages only meant for developers.
    – jksoegaard
    Jun 2, 2014 at 0:47
  • Sorry but I don't think this is actually correct. I'm pretty certain I was seeing the same messages a few months ago in the stable channel (alongside significant performance problems which resulted in me switching browser). And I'm pretty sure these particular messages are generated by the operating system as a hint to developers to fix their code, rather than being generated by the application itself.
    – Alistair McMillan
    Jul 2, 2014 at 23:00

1 Answer 1

Reset to default
3

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."

Improve this answer
0

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .