Masked browser crashes duplicated as renderer crash? IPC alive/ping?

[Dominik Röttsches]

(sorry, due to wrong From address when posing, sending this again to chromium-dev)

Hi,

in issue 561873 we're facing a long standing reported crash on a RELEASE_ASSERT for lack of a any last resort font. The renderer is unable to retrieve any last report font from system font APIs. The API calls are done through IPC, at least on Windows and Linux. 

For the majority of these crashes we don't have a reproduction, however in issue 676768 ClusterFuzz reported a browser side crash as a renderer crash, with a similar stack trace, as the issue above, i.e. lacking a last resort font. 

In this fuzzing issue, I am assuming this was probably due to the browser crashing and not replying to IPC in time, so that the renderer - now on its own - could not get a result for the last resort fallback font and crashed.

This leads me to the assumption that at least some of the reported renderer crashes for the first issue 561873 might be recorded as duplicates of a previous browser side crash.

In order to confirm this, is there a way I could do an IPC ping, or check from the renderer side whether the browser process is still alive and responding to IPC when reach the point of a null last resort font handle? Then I could potentially RELEASE_ASSERT on an unavailable/not-responding browser process and split out this portion from the crash reports.

Would someone familiar with IPC have any pointers on how to achieve that? Other opinions how to track this problem?

Thanks very much for your help,

Dominik

[Ken Rockot]

On Mon, Jan 9, 2017 at 7:24 AM, Dominik Röttsches <dr...@chromium.org> wrote:

(sorry, due to wrong From address when posing, sending this again to chromium-dev)

Hi,

in issue 561873 we're facing a long standing reported crash on a RELEASE_ASSERT for lack of a any last resort font. The renderer is unable to retrieve any last report font from system font APIs. The API calls are done through IPC, at least on Windows and Linux. 

For the majority of these crashes we don't have a reproduction, however in issue 676768 ClusterFuzz reported a browser side crash as a renderer crash, with a similar stack trace, as the issue above, i.e. lacking a last resort font. 

In this fuzzing issue, I am assuming this was probably due to the browser crashing and not replying to IPC in time, so that the renderer - now on its own - could not get a result for the last resort fallback font and crashed.

This leads me to the assumption that at least some of the reported renderer crashes for the first issue 561873 might be recorded as duplicates of a previous browser side crash.

In order to confirm this, is there a way I could do an IPC ping, or check from the renderer side whether the browser process is still alive and responding to IPC when reach the point of a null last resort font handle? Then I could potentially RELEASE_ASSERT on an unavailable/not-responding browser process and split out this portion from the crash reports.

If the browser actually crashes, the IPC channel necessarily becomes disconnected. Renderers detect this scenario ASAP and kill themselves. Adding a round-trip IPC to check for browser crash is not very helpful.

Could this be a browser hang instead? If the browser's hung there isn't really a path to recovery, but there's a chance it might be worth adding something if it can improve child process crash reports. AFAICT browser hangs typically manifest separately as different browser and/or renderer crash reports so I'm not sure we'd get anything out of that.

Would someone familiar with IPC have any pointers on how to achieve that? Other opinions how to track this problem?

Thanks very much for your help,

Dominik

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev