Automatically applying components based on crash stacktrace and information from OWNERS files.

If this is incorrect, please apply the Test-Predator-Wrong-Components label.

Predator and CL could not provide any possible suspects.

Using Code Search for the file, "platform_font_linux.cc" and observed there was some changes for the below file.

Suspect CL: https://chromium.googlesource.com/chromium/src/+/393cc78cf982dacd721f3616b0afb752d42d9c77%5E%21/ui/gfx/platform_font_linux.cc

jonross@ - Could you please check whether this is caused with respect to your change, if not please help us in assigning it to the right owner.

Thanks!

+dougt@chromium.org who worked on the code that is calling into this.

+erg@ font service
+mmenke@ who had insight in a similar issue

For more context on the crash:

gfx::PlatformFontLinux::PlatformFontLinux() CHECK failure
gfx::PlatformFont::CreateDefault()
...
...
content::RenderFrameImpl::DidFailProvisionalLoad
content::RenderFrameImpl::CommitFailedNavigation
content::mojom::FrameNavigationControlStubDispatch::Accept
....
Mojo stuff

This is similar to  issue 797510 , except here the Renderer is receiving a message after it has already started to shutdown. While processing this message attempts to show an error dialog accesses font. However the Font System shuts down before processing the request.

A workaround to this would be having mojo error handling code verifying that the process is alive before attempting to display error messages. Though we'd need that to start showing up everywhere, it doesn't scale.

mmenke@ suggested that font service shutdown could be blocked until all RenderFrames are destroyed. erg@ what are your thoughts on that?

over to erg. let me know what you'd want to do.

That sounds reasonable. Otherwise you're going to have reinitialization issues.

Reassigning back since I'm leaving.

Un-cc-ing me from all bugs on my final day.

This crash occurs very frequently on linux platform and is likely preventing the fuzzer marty_html_twiddler from making much progress. Fixing this will allow more bugs to be found.

Marking this bug as a blocker for next Beta release.

If this is incorrect, please add ClusterFuzz-Wrong label and remove the ReleaseBlock-Beta label.

+Oksana. This might be something good to look at soon.

I'm not sure I agree that it's a release blocker given a lack of actual crash reports from users.

Hello Doug,
I have tried reproducing this issue on my Linux machine 4 times (2 of them with --disable-xvfb) and for all of them got a message saying the original crash cannot be reproduced. I also did a 'redo task - check if bug still reproduces' at https://clusterfuzz.com/v2/testcase-detail/5527816855355392, but am not sure how to interpret the result:

[2018-03-27 19:47:52 UTC] oksamyt@chromium.org: Redo task(s): progression
[2018-03-27 20:20:31 UTC] clusterfuzz-linux-z4bj: Progression task started: r546213.
[2018-03-27 20:27:33 UTC] clusterfuzz-linux-z4bj: Progression task finished.

Is the crash expected to only be reproducible sometimes? Should I 'redo task' with different checkboxes checked? I am quite new to the project, so not familiar with this area yet.
Thanks!

A friendly reminder that M67 branch is coming soon on 04/12! Your bug is labelled as Beta ReleaseBlock, pls make sure to land the fix ASAP to trunk. This way we branch M67 from a high quality trunk. Thank you.

Hello Doug,
If this issue is really a release blocker, I would suggest assigning it to someone with expertise in the area of code that is involved. I tried reproducing locally with build 532829, but did not get any crashes. I'm also not sure how font_service is related since I don't see it in the stack trace from https://clusterfuzz.com/v2/testcase-detail/5527816855355392.
Thanks!

+sky@: Any UI owners that could look at this?

The font_service is not directly in the stack trace, as the error is detected in gfx::PlatformFontLinux::PlatformFontLinux code after returning from synchronous calls to the font_service

Depending on how the error occurs, the gfx::Font* code either tries to call to an already dead font_service. Or the font_service shuts down while the UI code is blocked waiting on the synchronous call to complete.

More details are captured in issue 744671

Re #16: How is font_service involved at all here? Is this a mash bug? I don't see any usage of the font_service outside of mash so it's not clear how it could be relevant.

My mistake, I hadn't realized that the font_service was currently restricted to only mash.

The CHECK failing in this case was added specifically to detect the cases I described in #16. As the service would install a custom font loader which was used by SKFont deriving code.

If that's not the case I'm unsure as to why there are no font available and the CHECK is firing.

Some preliminary analysis:

Since PlatformFontLinux::InitDefaultFont() returned false, it means that 
g_default_font.Get() was false (or null), which can happen in two cases:

1) g_default_font was never set to anything - previous calls to 
InitDefaultFont() were not made - not sure how likely for this case;
2) g_default_font was reset to nullptr - PlatformFontLinux::ReloadDefaultFont() 
- this is currently only called from FinishSwitchLanguage() in 
//chrome/browser/chromeos/base/locale_util.cc, so even less likely?

I will follow up with OSS-Fuzz team to see if it could be a machine configuration issue and whether there is a way to reproduce it on my machine.

According to crash/, there were 30 cases of this issue going back to version 62.
Here is the query I used, not sure how to create a link that will show the full summary:

product.name='Chrome_Linux' AND expanded_custom_data.ChromeCrashProto.ptype='renderer' AND expanded_custom_data.ChromeCrashProto.magic_signature_1.name='gfx::PlatformFontLinux::PlatformFontLinux'

Since the number of cases is low and it's not a recent regression, I will remove the ReleaseBlock-Beta label. Please adjust if neccessary.

Do we have a full stack here?

There's one in the clusterfuzz report, but it's just random renderer usage of a font.

To reiterate c#19 though, if we're seeing this check failure on Linux, that means fonts aren't working at all in the renderers. i.e. it's not a race or a shutdown issue or anything, just broken font support for the entire duration of the renderer's lifetime. That makes me suspect a configuration issue.

kojii, is this the same as bug 561873?

#24: hard to say for sure but probably unlikely.

Mass UI Triage, archiving old bugs.

ClusterFuzz testcase 5527816855355392 is still reproducing on tip-of-tree build (trunk).

If this testcase was not reproducible locally or unworkable, ignore this notification and we will file another bug soon with hopefully a better and workable testcase.

Otherwise, if this is not intended to be fixed (e.g. this is an intentional crash), please add ClusterFuzz-Ignore label to prevent future bug filing with similar crash stacktrace.