Strani errori di Google Chrome in system.log

Sto usando Mavericks e Google Chrome versione 34.0.1797.2 dev.

Questo è l'errore che ricevo:

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)

Qualche idea su cosa potrebbe causare questo? Ho cercato su Google e non ho trovato alcun indizio ...

google-chrome

— Paweł Gościcki
fonte

Vedo quel messaggio di log principalmente in combinazione con questo problema: dibattiti.apple.com/it/message/23755770#23755770 (Mavericks "esaurisce" i socket TCP.)

— Benjamin Riggs,

I primi due sono banali da spiegare: il sandbox sta registrando le smentite in modo che gli sviluppatori di Google possano risolvere quel codice poiché il sistema operativo sta negando l'accesso richiesto dal codice. L'ultimo messaggio potrebbe aver bisogno di qualcuno che guardi il codice sorgente di Chrome. Che problema causano? Puoi far apparire i messaggi a comando?

— bmike

Non sono sicuro di poterli innescare. Semplicemente non mi piacciono troppi messaggi di errore / avviso nei miei registri.

— Paweł Gościcki,

Se non ti piacciono i messaggi di avviso nei tuoi registri, semplicemente non dovresti eseguire versioni "dev" del software. Nel caso di Chrome, ciò significa che il software non è destinato alla versione generale e che molto probabilmente contiene bug e forse messaggi di avviso destinati esclusivamente agli sviluppatori.

— jksoegaard,

Mi dispiace ma non penso che questo sia effettivamente corretto. Sono abbastanza sicuro di aver visto gli stessi messaggi qualche mese fa nel canale stabile (insieme a significativi problemi di prestazioni che mi hanno portato a cambiare browser). E sono abbastanza sicuro che questi messaggi particolari siano generati dal sistema operativo come suggerimento per gli sviluppatori di correggere il loro codice, piuttosto che essere generati dall'applicazione stessa.

— Alistair McMillan,

Come forse saprai, Google Chrome funziona come un'applicazione multi-processo . Hai il tuo processo iniziale "Google Chrome" che gestisce l'interfaccia utente e riproduce "host" per una serie di altri processi. Viene creato un nuovo processo "renderer" per ogni scheda aperta in Chrome, un processo "plug-in" per ogni estensione installata e esiste un processo "GPU" separato per il codice che comunica con la GPU del sistema. Ognuno di questi altri processi viene visualizzato in Activity Monitor come processo "Google Chrome Helper".

Per rendere Chrome più sicuro, i processi di rendering vengono eseguiti in una sandbox . Sono in grado di comunicare con la rete solo attraverso il processo host e possono parlare solo con file specifici (ad esempio font e profili ColorSync). Inoltre, viene loro impedito di parlare con altri processi nel sistema, che è ciò che causa questi messaggi di log. I processi di rendering stanno provando a parlare con i processi launchserviced e windowservice, ma gli viene impedito di farlo a causa della loro sandbox.

Questo errore è stato risolto da un ingegnere del software del team Chrome Security di Google con un commit a febbraio 2014. La rimozione di questa riga di codice ha risolto il problema.

[NSApplication sharedApplication];

Tra le altre cose, la chiamata del metodo sharedApplication apre una connessione tra un'applicazione e WindowServer di OS X, che si può verificare con l'errore CGSLookupServerRootPort.

L'intenzione era che Chrome chiamasse questo metodo per "riscaldare" determinate risorse prima di abilitare il sandbox; ottenere l'accesso a determinati file, processi o risorse di rete prima che le restrizioni sandbox entrassero in vigore. Tuttavia sembra che ad un certo punto questo tentativo abbia iniziato a fallire, causando questi errori nel registro. La mia ipotesi è che Apple abbia considerato questo "riscaldamento" un tentativo di imbrogliare il sandbox e ha iniziato a reprimerlo.

Se sto leggendo correttamente questa modifica ha raggiunto il canale di rilascio stabile con un aggiornamento di Google Chrome a 34.0.1847.131 ad aprile 2014.

È interessante notare che il team di Chrome aveva discusso della rimozione di queste chiamate al metodo sharedApplication nell'ottobre 2013 e aveva persino discusso della rimozione di Cocoa dai processi di rendering come obiettivo nel 2009.

Su una nota correlata, Apple ha rilasciato una correzione di sicurezza nell'aprile 2014 per risolvere un bug in cui "Le sessioni WindowServer potevano essere create da applicazioni sandbox".

— Alistair McMillan
fonte