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

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

Automatically assigning owner based on suspected regression changelist https://chromium.googlesource.com/chromium/src/+/28200c1611ecebd029de9a0caf2a7fda3a7d5c47 (Convert //ui to use ComPtr).

If this is incorrect, please remove the owner and apply the Test-Predator-Wrong-CLs label.

Testcase 5628424843689984 is a top crash on ClusterFuzz for linux platform. Please prioritize fixing this crash.

Marking this crash as a Beta release blocker.

If this is incorrect, please add ClusterFuzz-Wrong label and re-open the issue.

robliao@ Gentle Ping! This issue is marked as RB-Beta for M65, could you please let us know is there any latest update available on this issue?

Thanks!

robliao@ Sine this issue is marked as RB-Beta, would you mind taking a look in to this issue? 

Thanks!

The referenced CL is a no-op change due to 
template <typename T>
using ScopedComPtr = Microsoft::WRL::ComPtr<T>;

Predator and CL could not provide any possible suspects.

Using Code Search for the file, "platform_font_linux.cc" and observed there was some recent 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!

+reillyg@ could you help take a look at this issue?

The error in platform_font_linux.cc is triggered when there are no system resources available. One of the primary ways in which this occurs is if we try to access fonts during a system shutdown.

Looking at the full stack trace, the eventual call into fonts is from a mojo connection error handler: content::ThrottlingURLLoader::OnClientConnectionError. We likely need to detect that the system is shutdown when this connection fails, and in that case not attempt to display text.

reillyg@ Ping! This issue is marked as RB-Beta, could you please let us know is there any latest update available on this issue?

Thanks!

jonross@, when you say system shutdown do you mean OS shutdown or Chrome shutdown? This CHECK is occurring in a render process. I'm suspicious that this is a CHECK at all as it seems like it can be triggered by issues with the system environment.

The ThrottlingURLLoader code is pretty far away from font rendering in the crash stack. If we were to put in a check that we should abort any attempt to display anything because the process is about to exit it should probably be somewhere around blink::DocumentLoader::LoadFailed.

+erg@ who owns font_service

I meant Chrome shutdown.

We added this as a CHECK so that we could identify code that wasn't setup to handle re-entrancy caused by mojo. We expect that OS shutdowns triggering this would be fewer in number reports.

There are two possible points of re-entrancy here. One is issue 744671 the font_service mojo api is synchronous. This means that all calls into font code is actually re-entrant. Chrome could have been shutdown while calling code was blocked requesting a font.

The other is that content::ThrottlingURLLoader::OnClientConnectionError() can be ran after other parts of Chrome have already shutdown. But I agree that there might be a more central location to perform the process exiting, instead of attempting to display anything

I'm not familiar with the renderer shutdown process but it seems that if we know the process is shutting down then existing ThrottlingURLLoader instances should be destroyed (I believe they're owned by the ResourceDispatcher). That will prevent OnClientConnectionError() from being called later in shutdown.

jonross@ Gentle Ping! This issue is marked as RB-Beta for M65, could you please let us know is there any latest update available on this issue?

Thanks!

+jam@ who has been working with ThrottlingURLLoader. We have found a case where we attempt to access resource files during Chrome shutdown, after they are no longer available. Could you comment on #12 ?

The renderer cannot reliably know if a request it's about to make will reach the browser after the browser has started shutdown, so I think any solution which attempts to change renderer behavior based on shutdown state would necessarily still be racy. What am I missing?

Why do we still have pending requests after we've shut down the font system?  Seems to me like we should destroy all RenderFrames before shutting down the font service, no?  That would mean there's nothing left to call into the font service.

The pending requests can also occur as a side effect of the font system using synchronous mojo calls.
  - Pending request made
  - Font System shuts down before processing request
  - Pending request resumes execution.

Blocking the font service shutdown on destroying all render frames could solve this particular case.

Any thoughts on that erg@ ?

ClusterFuzz testcase 5628424843689984 is flaky and no longer crashes, so closing issue.

If this is incorrect, please add ClusterFuzz-Wrong label and re-open the issue.