Issue metadata
Sign in to add a comment
|
Windows font precaching hangs printing from the Cloud Print Service |
||||||||||||||||||||||
Issue descriptionChrome Version: 66.0.3347.0 OS: Windows What steps will reproduce the problem? (1) Install Chrome 66.0.3347.0 as Chrome Stable channel (2) Set up the Cloud Print Service with a shared printer (3) Try to print a PDF to the shared printer What is the expected result? Successful print job. What happens instead? The print job never finishes. The Cloud Print Service runs as the service process. It spawns a sandboxed child to to PDF to EMF conversion. The child process is trying to precache fonts so they can be correctly rendered, but nobody is handling the precache request, and both processes get stuck waiting on each other. This issue started with r519471 converting the precache font IPC to Mojo. After fixing bug 799699 and bug 809888 , this is the next problem that has finally revealed itself. In particular, [1] removed the IPC message filter in ChildProcessHostImpl but did not replace it. This was not a problem initially because the same CL also made the replacement Mojo call asynchronous. Once r536457 landed to correct that, this bug started happening. I tried fixing this but can't get Mojo to do the right thing. PTAL, as this may help solve bug 810791 . [1] https://chromium.googlesource.com/chromium/src/+/33a2d10d42fcb82679cc9fb5642153a0d4ac9b50%5E%21/#F5
,
Feb 16 2018
I should be able to fix this pretty quickly assuming your analysis is accurate. I'll try to hack something together right now.
,
Feb 16 2018
Hmm. Looking more closely at the code it actually seems OK to me. The message filter was replaced by adding the interface binder through content::RegisterCommonBrowserInterfaces, which applies to all child process connections. I also don't understand how making the call synchronous would reveal a bug that wasn't obvious already. e.g., if the interface weren't bound in the browser at all, the sync call would fail quickly.
,
Feb 18 2018
The Cloud Print Service is the weirdo in chrome/service. It doesn't call into any browser code, including content::RegisterCommonBrowserInterfaces(). All I know is the child process is hanging, and when I attach to it via WinDbg, it's waiting around for the sync call to return. It did not fail earlier. No idea why. I tried building with DCHECKs enabled, but nothing failed with DCHECKs on either.
,
Feb 19 2018
,
Feb 19 2018
Oh right. The utility process in question is hosted by cloud print proxy (i.e. the "service process") and not the browser process. RegisterCommonBrowserInterfaces isn't called in the service process. The plumbing to change that is quite gnarly too. I'm going to attempt to work out a simpler alternative. For posterity, the reason this hangs instead of failing is that the service process only partially emulates a Service Manager. It ignores all incoming requests (such as requests to connect to another service), letting them accumulate silently in an unbound message pipe.
,
Feb 19 2018
https://chromium-review.googlesource.com/c/chromium/src/+/924985 is a CL which should address this. I don't have a Windows development environment at my disposal right now, so thestig@ if you can help test this that would be most appreciated. Thanks :)
,
Feb 20 2018
Thanks. Building and testing patch set 4...
,
Feb 20 2018
,
Feb 20 2018
,
Feb 21 2018
M65 Stable promotion is coming VERY soon. Your bug is labelled as Stable ReleaseBlock, pls make sure to land the fix and request a merge into the release branch ASAP. Merge has to happen latest by 4:00 PM PT Monday (02/26/18) in order to make it to last M65 beta release next week. Thank you.
,
Feb 22 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/4823ab8487f73dfd2655aefbb32050784caa1be5 commit 4823ab8487f73dfd2655aefbb32050784caa1be5 Author: Ken Rockot <rockot@chromium.org> Date: Thu Feb 22 23:33:32 2018 Give "service" process its own Service Manager(s) The cloud print proxy process (i.e. legacy "service" process) may launch utility processes to do some out-of-process work. These utility processes behave much like utility processes launched by the browser process, and occasionally they request an interface from the browser in order to get some work done. Font caching behavior on Windows is exposed by the browser and is sometimes needed from utility processes launched by the cloud print process, but we don't currently have any way for the cloud print process to expose interfaces back to utility processes. Such interface requests will instead be silently ignored. This CL gives every ServiceUtilityProcessHost its own isolated Service Manager instance which knows how to route interface requests between the service process and the single utility process launched by that host. This in turn allows us to reuse common host interface registration code to expose some interfaces from the service process. TBR=dcheng@chromium.org Bug: 813101 Change-Id: I763033215d13535ba545ded7ef7e22fe5484b414 Reviewed-on: https://chromium-review.googlesource.com/924985 Commit-Queue: Ken Rockot <rockot@chromium.org> Reviewed-by: Daniel Cheng <dcheng@chromium.org> Reviewed-by: Ken Rockot <rockot@chromium.org> Reviewed-by: Lei Zhang <thestig@chromium.org> Reviewed-by: John Abd-El-Malek <jam@chromium.org> Cr-Commit-Position: refs/heads/master@{#538617} [modify] https://crrev.com/4823ab8487f73dfd2655aefbb32050784caa1be5/chrome/service/BUILD.gn [modify] https://crrev.com/4823ab8487f73dfd2655aefbb32050784caa1be5/chrome/service/DEPS [modify] https://crrev.com/4823ab8487f73dfd2655aefbb32050784caa1be5/chrome/service/service_utility_process_host.cc [modify] https://crrev.com/4823ab8487f73dfd2655aefbb32050784caa1be5/chrome/service/service_utility_process_host.h [modify] https://crrev.com/4823ab8487f73dfd2655aefbb32050784caa1be5/content/browser/renderer_host/render_message_filter.cc [modify] https://crrev.com/4823ab8487f73dfd2655aefbb32050784caa1be5/content/browser/service_manager/common_browser_interfaces.cc [modify] https://crrev.com/4823ab8487f73dfd2655aefbb32050784caa1be5/content/child/child_thread_impl.h [modify] https://crrev.com/4823ab8487f73dfd2655aefbb32050784caa1be5/content/common/BUILD.gn [modify] https://crrev.com/4823ab8487f73dfd2655aefbb32050784caa1be5/content/common/font_cache_dispatcher_win.cc [modify] https://crrev.com/4823ab8487f73dfd2655aefbb32050784caa1be5/content/public/common/BUILD.gn [rename] https://crrev.com/4823ab8487f73dfd2655aefbb32050784caa1be5/content/public/common/font_cache_dispatcher_win.h [rename] https://crrev.com/4823ab8487f73dfd2655aefbb32050784caa1be5/content/public/common/font_cache_win.mojom
,
Feb 23 2018
Printing from the Cloud Print Service should work now. I filed bug 814984 for the next issue.
,
Feb 23 2018
[Auto-generated comment by a script] We noticed that this issue is targeted for M-65; it appears the fix may have landed after branch point, meaning a merge might be required. Please confirm if a merge is required here - if so add Merge-Request-65 label, otherwise remove Merge-TBD label. Thanks.
,
Feb 23 2018
I can build M65 locally with r538617 applied to make sure it works as expected.
,
Feb 23 2018
Pls test/verify this bug on canary and request a merge to M65.
,
Feb 23 2018
Local testing with r538617 merged to the M65 branch fixes the hanging Cloud Print Service.
,
Feb 23 2018
This bug requires manual review: We are only 10 days from stable. Please contact the milestone owner if you have questions. Owners: cmasso@(Android), cmasso@(iOS), bhthompson@(ChromeOS), govind@(Desktop) For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Feb 23 2018
Thank you thestig@. Will you be able to verify on tonight's canary?
,
Feb 23 2018
Yes, I can verify with 66.0.3353.0+ as well when it is ready.
,
Feb 23 2018
Great, pls update the bug with canary result tomorrow. Thank you.
,
Feb 23 2018
Canary works as expected.
,
Feb 23 2018
TE team do not have shared printer to verify this issue. As per comment#23 this fix is verified on latest canary. @thestig: Does this require any verification from test team? Please let us know if so. Thanks!
,
Feb 23 2018
The NextAction date has arrived: 2018-02-23
,
Feb 23 2018
re: comment 24 - viveksr@ did the testing yesterday for M64. Please get in touch with them regarding the verification tests.
,
Feb 23 2018
viveksr@, could you pls verify this bug on canary?
,
Feb 23 2018
In any case, the merge is ready to go: https://chromium-review.googlesource.com/933873
,
Feb 26 2018
viveksr@, did you get chance to verify this on Friday on canary?
,
Feb 26 2018
Printer Used : Lexmark a) Mac: Installed Chrome version 66.0.3350.0 on MAC(OSX Yosemite) and tested Cloud Print on Linux was able to print all pdf files without any issues. (used the ones as well that originally had the issue in printing) b) Windows: Installed Chrome version 66.0.3350.0 and tested Cloud Print on Windows 10 Pro N was able to print all pdf files as well without any issues. c) Linux: Installed Chrome version 66.0.3350.0 and tested Cloud Print on Linux. Was able to print all pdf files as well without any issues.
,
Feb 26 2018
viveksr@, just wanted to make sure did you test on canary version 66.0.3353.0 or higher? 66.0.3350.0 doesn't include the fix landed at #13.
,
Feb 26 2018
Approving merge to M65 branch 3325 based on comment #23 and https://bugs.chromium.org/p/chromium/issues/detail?id=814984#c13.
,
Feb 26 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/be93137cbb7ef6cc672231b8abbfde2271ddf6c9 commit be93137cbb7ef6cc672231b8abbfde2271ddf6c9 Author: Lei Zhang <thestig@chromium.org> Date: Mon Feb 26 23:01:24 2018 M65: Give "service" process its own Service Manager(s) The cloud print proxy process (i.e. legacy "service" process) may launch utility processes to do some out-of-process work. These utility processes behave much like utility processes launched by the browser process, and occasionally they request an interface from the browser in order to get some work done. Font caching behavior on Windows is exposed by the browser and is sometimes needed from utility processes launched by the cloud print process, but we don't currently have any way for the cloud print process to expose interfaces back to utility processes. Such interface requests will instead be silently ignored. This CL gives every ServiceUtilityProcessHost its own isolated Service Manager instance which knows how to route interface requests between the service process and the single utility process launched by that host. This in turn allows us to reuse common host interface registration code to expose some interfaces from the service process. TBR=rockot@chromium.org Bug: 813101 Change-Id: I763033215d13535ba545ded7ef7e22fe5484b414 Reviewed-on: https://chromium-review.googlesource.com/924985 Commit-Queue: Ken Rockot <rockot@chromium.org> Reviewed-by: Daniel Cheng <dcheng@chromium.org> Reviewed-by: Ken Rockot <rockot@chromium.org> Reviewed-by: Lei Zhang <thestig@chromium.org> Reviewed-by: John Abd-El-Malek <jam@chromium.org> Cr-Original-Commit-Position: refs/heads/master@{#538617} Reviewed-on: https://chromium-review.googlesource.com/933873 Cr-Commit-Position: refs/branch-heads/3325@{#598} Cr-Branched-From: bc084a8b5afa3744a74927344e304c02ae54189f-refs/heads/master@{#530369} [modify] https://crrev.com/be93137cbb7ef6cc672231b8abbfde2271ddf6c9/chrome/service/BUILD.gn [modify] https://crrev.com/be93137cbb7ef6cc672231b8abbfde2271ddf6c9/chrome/service/DEPS [modify] https://crrev.com/be93137cbb7ef6cc672231b8abbfde2271ddf6c9/chrome/service/service_utility_process_host.cc [modify] https://crrev.com/be93137cbb7ef6cc672231b8abbfde2271ddf6c9/chrome/service/service_utility_process_host.h [modify] https://crrev.com/be93137cbb7ef6cc672231b8abbfde2271ddf6c9/content/browser/renderer_host/render_message_filter.cc [modify] https://crrev.com/be93137cbb7ef6cc672231b8abbfde2271ddf6c9/content/browser/service_manager/common_browser_interfaces.cc [modify] https://crrev.com/be93137cbb7ef6cc672231b8abbfde2271ddf6c9/content/child/child_thread_impl.h [modify] https://crrev.com/be93137cbb7ef6cc672231b8abbfde2271ddf6c9/content/common/BUILD.gn [modify] https://crrev.com/be93137cbb7ef6cc672231b8abbfde2271ddf6c9/content/common/font_cache_dispatcher_win.cc [modify] https://crrev.com/be93137cbb7ef6cc672231b8abbfde2271ddf6c9/content/public/common/BUILD.gn [rename] https://crrev.com/be93137cbb7ef6cc672231b8abbfde2271ddf6c9/content/public/common/font_cache_dispatcher_win.h [rename] https://crrev.com/be93137cbb7ef6cc672231b8abbfde2271ddf6c9/content/public/common/font_cache_win.mojom
,
Feb 26 2018
My applogies the Chrome version is Google Chrome 66.0.3353.0 (Official Build) (64-bit) for the tests Revision 545e59b4d718e55d2fa80a0a6c104de9236a0eda-refs/heads/master@{#538677} for Mac, Windows and Linux Anita by mistake picked up the chrome version from the wrong instance
,
Feb 26 2018
No worries, thank you for clarification.
,
Feb 28 2018
Verified with 65.0.3325.106 - installed as Stable channel on Windows 10, registered & started GCP service, and successfully printed to the shared printer from another machine.
,
Mar 1 2018
Printer Used : Lexmark On Mac: Installed Chrome version 65.0.3325.106 on MAC and tested Cloud Print , able to print all pdf, Jpeg, png, xls files without any issues. Verified printing different sizes of pdf files, was able to print without issues. On Windows: Installed Chrome version 65.0.3325.106 and tested Cloud Print on Windows 10 Pro N was able to print all pdf ,jpeg, png, xls files without any issues. Verified printing different sizes of pdf files, was able to print without issues. |
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by thestig@chromium.org
, Feb 16 2018