Erreurs Google Chrome étranges dans system.log

J'utilise Mavericks et Google Chrome Version 34.0.1797.2 dev.

Voici l'erreur que je reçois:

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)

Une idée sur ce qui pourrait être à l'origine de cela? J'ai cherché sur Google et je n'ai trouvé aucun indice ...

google-chrome Paweł Gościcki
la source

Je vois ce message de journal principalement en conjonction avec ce problème: discussions.apple.com/message/23755770#23755770 (Mavericks «manque» de sockets TCP.)

Benjamin Riggs

Les deux premiers sont triviaux à expliquer - le bac à sable enregistre les refus afin que les développeurs de google puissent corriger ce code car le système d'exploitation refuse l'accès demandé par le code. Le dernier message pourrait être besoin de quelqu'un pour regarder le code source de chrome. Quel problème cela cause-t-il? Pouvez-vous faire apparaître les messages sur commande?

bmike

Je ne sais pas si je peux les déclencher. Je n'aime tout simplement pas trop de messages d'erreur / d'avertissement dans mes journaux.

Paweł Gościcki

Si vous n'aimez pas les messages d'avertissement dans vos journaux, vous ne devez tout simplement pas exécuter les versions "dev" du logiciel. Dans le cas de Chrome, cela signifie que le logiciel n'est pas destiné à une version générale et qu'il contient très probablement des bogues et peut-être des messages d'avertissement destinés uniquement aux développeurs.

jksoegaard

Désolé mais je ne pense pas que ce soit correct. Je suis pratiquement certain d'avoir vu les mêmes messages il y a quelques mois sur le canal stable (à côté de problèmes de performances importants qui m'ont amené à changer de navigateur). Et je suis presque sûr que ces messages particuliers sont générés par le système d'exploitation comme un indice pour les développeurs de corriger leur code, plutôt que d'être générés par l'application elle-même.

Alistair McMillan

Réponses:

Comme vous le savez peut-être, Google Chrome fonctionne comme une application multi-processus . Vous avez votre processus "Google Chrome" initial qui gère l'interface utilisateur et joue "hôte" à un certain nombre d'autres processus. Un nouveau processus de "rendu" est créé pour chaque onglet que vous ouvrez dans Chrome, un processus de "plug-in" pour chaque extension que vous installez, et il existe un processus "GPU" distinct pour le code qui communique avec le GPU du système. Chacun de ces autres processus apparaît dans le Moniteur d'activité en tant que processus "Google Chrome Helper".

Pour rendre Chrome plus sécurisé, les processus de rendu s'exécutent dans un bac à sable . Ils ne peuvent parler au réseau que via le processus hôte et ne peuvent parler qu'à des fichiers spécifiques (par exemple, les polices et les profils ColorSync). Ils sont également empêchés de parler à d'autres processus du système, ce qui est à l'origine de ces messages de journal. Les processus de rendu tentent de communiquer avec les processus launchserviced et windowservice, mais ne peuvent pas le faire en raison de leur sandbox.

Ce bug a été résolu par un ingénieur logiciel de l'équipe Google Chrome Security avec un commit en février 2014. La suppression de cette seule ligne de code a résolu le problème.

[NSApplication sharedApplication];

Entre autres choses, l'appel de la méthode sharedApplication ouvre une connexion entre une application et WindowServer d'OS X, que vous pouvez voir échouer dans l'erreur CGSLookupServerRootPort.

L'intention était que Chrome appelle cette méthode pour «réchauffer» certaines ressources avant d'activer le bac à sable; accéder à certains fichiers, processus ou ressources réseau avant la mise en place des restrictions sandbox. Cependant, il semble qu'à un moment donné, cette tentative a commencé à échouer, entraînant ces erreurs dans le journal. Je suppose qu'Apple a considéré cet "échauffement" comme une tentative de tromper le bac à sable et a commencé à le réprimer.

Si je lis correctement, ce changement a atteint le canal de publication stable avec une mise à jour de Google Chrome vers 34.0.1847.131 en avril 2014.

Il est intéressant de noter que l'équipe Chrome avait discuté de la suppression de ces appels à la méthode sharedApplication en octobre 2013 et avait même envisagé de supprimer Cocoa entièrement des processus de rendu comme objectif en 2009.

Sur une note connexe, Apple a publié un correctif de sécurité en avril 2014 pour résoudre un bogue où «les sessions WindowServer pouvaient être créées par des applications en bac à sable».

Alistair McMillan
la source