Closed Bug 1501121 Opened 1 year ago Closed 1 year ago
[Mac] With sandbox early startup enabled, content processes become "Not Responding" in Activity Monitor
Bug 1501121 - [Mac] With sandbox early startup enabled, content processes become "Not Responding" in Activity Monitor r?Alex_Gaynor
46 bytes, text/x-phabricator-request
|Details | Review|
With security.sandbox.content.mac.earlyinit=true (introduced with bug 1431441), content processes are listed as "Not Responding" in the macOS Activity Monitor. See bug 1498845 which was filed when earlyinit was previously enabled on Nightly. This problem is due to the earlyinit=true implementation failing to call CGSShutdownServerConnections() after enabling the content sandbox. We added the call to CGSShutdownServerConnections() in bug 1481304 specifically to drop the connection to the windowserver and prevent "Not Responding" which became an issue when we removed the native event loop. With the call to CGSShutdownServerConnections() added back, content processes were displayed normally in Activity Monitor. Tested on 10.14 and 10.11.
With CGSShutdownServerConnections() added back, I've noticed that the generic application icon is no longer displayed in Activity Monitor for content processes and instead we have no icon. I did some experimenting with adding coreservices, launchservices, and distnoted to the policy, but it didn't bring the icon back. I think it's acceptable to not have the icon for child processes in Activity Monitor. CLI applications do not have icons and neither do some of the helper processes for Google Chrome and Safari. CGSShutdownServerConnections() does have to be called after SetProcessName() which appears to be the first call made that opens the WindowServer connection. Otherwise CGSShutdownServerConnections() hangs in internal SkyLight`initDisplayState() (presumably blocked waiting for the WindowServer). Once we remove the connection to the WindowServer, we'll have to either avoid calling SetProcessName() or find an alternative implementation that doesn't depend on the WindowServer connection. Alternatively, we could just set a name in the plugin-container.app Info.plist. I'll file a bug to document this and associate it with a windowserver removal bug. The changes add back use of the SendSetProcessSandbox() message for the earlyinit mode for the call to CGSShutdownServerConnections().
Just wanted to confirm that yes, it hangs if you call shutdown when there are no open windowserver connections. I filed a bug with Apple on this and haven't heard anything from them about it :-)
When early sandbox setartup is enabled, revert to sending SetProcessSandbox() to the child process as before. In the child process RecvSetProcessSandbox() handler, call CGSShutdownServerConnections() and then return early if the sandbox is already enabled.
Pushed by firstname.lastname@example.org: https://hg.mozilla.org/integration/autoland/rev/141e7c1fa433 [Mac] With sandbox early startup enabled, content processes become "Not Responding" in Activity Monitor r=Alex_Gaynor
(In reply to Haik Aftandilian [:haik] from comment #1) > Once we remove the connection to the WindowServer, we'll have > to either avoid calling SetProcessName() or find an alternative > implementation that doesn't depend on the WindowServer connection. > Alternatively, we could just set a name in the plugin-container.app > Info.plist. I'll file a bug to document this and associate it with a > windowserver removal bug. I did some testing with security.sandbox.content.mac.earlyinit=true and security.sandbox.content.mac.disconnect-windowserver=true and found that the SetProcessName() appeared to work (as reported by Activity Monitor) and CGSShutdownServerConnections() didn't block. lsmp output showed no WindowServer. I did run into an issue on Mojave where form controls weren't rendering just like in bug 1502228. On 10.11, the form controls were OK. When we are ready to remove our connection to the WindowServer (bug 1467758), we'll have to fix this. Will file a new bug and make it block bug 1467758.
You need to log in before you can comment on or make changes to this bug.