When the --no-zygote flag is specified chrome CHECK fails and font fallback is broken |
|||
Issue description
Chrome Version: 60.0.3074.0 (Developer Build) (64-bit)
OS: Ubuntu Linux
What steps will reproduce the problem?
(1) Download the attached HTML file
(2) Run headless Chrome with no zygote:
cr run chrome --no-zygote --no-sandbox --headless --remote-debugging-port=9222 file://above/file/index.html
(3) Notice that Chrome crashes due to browser_main_loop.cc's SetupSandbox not calling "RenderSandboxHostLinux::GetInstance()->Init()"
(4) Change browser_main_loop.cc's SetupSandbox to call above function and avoid the crash, and then open the page again.
(5) View the Emoji and Japanese text's rendered font using devtools style inspector in the remote debugging port.
(6) Verify that the Emoji and Japanese text are using the last-resort fallback font [1] (DejaVu Sans for me).
What is the expected result?
No crash. Fonts besides the last resort fallback font should be used if they are installed (For example Noto Emoji may be used for the emoji if it is installed).
What happens instead?
Crash. Wrong fonts. For me the Japanese text appears as blank squares, but that could depend on the last resort fallback font.
[1]
https://cs.chromium.org/chromium/src/third_party/WebKit/Source/platform/fonts/skia/FontCacheSkia.cpp?rcl=1840bcd0f90cc5e22225ca37d3751c5f398ab2d0&l=144
,
Apr 18 2017
Summary of why the last resort fallback font is chosen: 1. Skipping "RenderSandboxHostLinux::GetInstance()->Init()", in addition to crashing Chrome, means that the GetSandboxFD() is never initialized, despite being required by the font code if sandboxEnabled return true [1]. 2. when zygote is disabled FontConfigIPC is never set to the SkFontConfigInterface [2] The first issue prevents font selection from working (IPC breaks so it uses an empty font description), and the second issue prevents font loading from working (It tries to load based off fontconfigInterfaceId instead of filename) [1] https://cs.chromium.org/chromium/src/content/child/child_process_sandbox_support_impl_linux.cc?rcl=86767028eea938a79b9b814ca3fe6f4396e38387&l=87 [2] https://cs.chromium.org/chromium/src/content/zygote/zygote_main_linux.cc?rcl=dfc326b3c2dc9801898bba2d0f1cd2de52f83c9d&l=374
,
Apr 20 2017
There is a TSan data race report if zygote is disabled, "RenderSandboxHostLinux::GetInstance()->Init()" is run, and the fontconfig sandbox code is enabled (RendererBlinkPlatformImpl::sandboxEnabled() returns true). See attached.
,
Apr 20 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/9dc1413a9f8a803109530c02aeb4429a8856e525 commit 9dc1413a9f8a803109530c02aeb4429a8856e525 Author: zoeclifford <zoeclifford@chromium.org> Date: Thu Apr 20 22:36:30 2017 Initialize RenderSandboxHostLinux in --no-zygote mode to not crash. http://crrev.com/2384163002 skipped initializing RenderSandboxHostLinux If the sandbox and zygote are both disabled. But the RendererSocket is used even in this case by the Linux ChildProcessLauncherHelper, so it lead to a crash. Instead initialize the RenderSandboxHostLinux unconditionally. This appears to be what some code expects in multi-process code. Tested: cr run chrome --no-zygote --no-sandbox http://www.google.com BUG= 712779 Review-Url: https://codereview.chromium.org/2827783003 Cr-Commit-Position: refs/heads/master@{#466168} [modify] https://crrev.com/9dc1413a9f8a803109530c02aeb4429a8856e525/content/browser/browser_main_loop.cc [modify] https://crrev.com/9dc1413a9f8a803109530c02aeb4429a8856e525/content/zygote/zygote_browsertest.cc
,
May 15 2017
,
May 17 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/525974cdba654d1611d169a34397304334797175 commit 525974cdba654d1611d169a34397304334797175 Author: zoeclifford <zoeclifford@chromium.org> Date: Wed May 17 20:31:06 2017 Initialize FontConfigIPC when zygote is disabled so font fallback works. Normally FontConfigIPC is set from zygote_main_linux, but this can't happen if zygote is disabled, either from the --no-zygote flag or the --renderer-cmd-prefix flag. This is a problem because the renderer's font code uses the linux sandbox IPC logic even if --no-sandbox is set. This code mostly works but fallback font loading fails because when FontConfigIPC isn't set, SkFontConfigInterfaceDirect is used instead, and it doesn't know how to deal with fontconfiginterfaceids. This causes the last resort fallback font to always be chosen, even when a more appropriate font is available. To fix this, simply initialize FontConfigIPC even when zygote is disabled. This lets the existing code work, and allows fallback fonts to be loaded. Manually tested with the test-case in http://crbug.com/712779 BUG= 712779 Review-Url: https://codereview.chromium.org/2833973003 Cr-Commit-Position: refs/heads/master@{#472553} [add] https://crrev.com/525974cdba654d1611d169a34397304334797175/content/browser/linux_ipc_browsertest.cc [modify] https://crrev.com/525974cdba654d1611d169a34397304334797175/content/browser/renderer_host/render_process_host_impl.cc [modify] https://crrev.com/525974cdba654d1611d169a34397304334797175/content/browser/renderer_host/sandbox_ipc_linux.cc [modify] https://crrev.com/525974cdba654d1611d169a34397304334797175/content/browser/renderer_host/sandbox_ipc_linux.h [modify] https://crrev.com/525974cdba654d1611d169a34397304334797175/content/renderer/renderer_main.cc [modify] https://crrev.com/525974cdba654d1611d169a34397304334797175/content/test/BUILD.gn [add] https://crrev.com/525974cdba654d1611d169a34397304334797175/content/test/data/font/font_fallback.html
,
May 17 2017
|
|||
►
Sign in to add a comment |
|||
Comment 1 by zoeclifford@chromium.org
, Apr 18 2017Status: Assigned (was: Untriaged)