Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix: render process crash handling #34428

Merged
merged 4 commits into from Jun 3, 2022

Conversation

samuelmaddock
Copy link
Member

Description of Change

#34411 didn't have a repro case by the time of merging. This PR includes a test which reproduced the crash prior to the fix.

Additionally, another crash was found while testing same-origin crash recovery. That fix is included as well.

Checklist

Release Notes

Notes: Fixed a crash when loading a same-origin URL after a render process crash.

Could occur when a renderer crashes and the same-origin URL is loaded again
which leads to reusing the renderer process.
@electron-cation electron-cation bot added the new-pr 🌱 PR opened in the last 24 hours label Jun 2, 2022
@samuelmaddock samuelmaddock added semver/patch backwards-compatible bug fixes and removed new-pr 🌱 PR opened in the last 24 hours labels Jun 2, 2022
@electron-cation electron-cation bot added the new-pr 🌱 PR opened in the last 24 hours label Jun 2, 2022
@samuelmaddock samuelmaddock added target/18-x-y and removed new-pr 🌱 PR opened in the last 24 hours labels Jun 2, 2022
@electron-cation electron-cation bot added the new-pr 🌱 PR opened in the last 24 hours label Jun 2, 2022
@samuelmaddock
Copy link
Member Author

Tests failing due to DCHECK() added in #34411, investigating now.

@samuelmaddock
Copy link
Member Author

The DCHECK(render_frame_) case was being hit from here:

auto* web_frame = WebFrameMain::FromRenderFrameHost(render_frame_host);
if (web_frame)
web_frame->MaybeSetupMojoConnection();

This occurs when the RFH has crashed and a new one is setup for same-origin navigation while the existing WebFrameMain reference is kept alive.

First RenderFrameCreated is called with the newly created RFH. It looks up the corresponding WebFrameMain instance by the FrameTreeNode ID. It exists, but remains in a disposed state due to the old RFH being killed by a crash.

void WebContents::RenderFrameCreated(
content::RenderFrameHost* render_frame_host) {
HandleNewRenderFrame(render_frame_host);

Then RenderFrameHostChanged is called which will swap the RFH referenced by the WebFrameMain instance. Finally it will setup the mojo connection.

void WebContents::RenderFrameHostChanged(content::RenderFrameHost* old_host,
content::RenderFrameHost* new_host) {
// During cross-origin navigation, a FrameTreeNode will swap out its RFH.
// If an instance of WebFrameMain exists, it will need to have its RFH
// swapped as well.
//
// |old_host| can be a nullptr so we use |new_host| for looking up the
// WebFrameMain instance.
auto* web_frame =
WebFrameMain::FromFrameTreeNodeId(new_host->GetFrameTreeNodeId());
if (web_frame) {
web_frame->UpdateRenderFrameHost(new_host);
}
}

@VerteDinde VerteDinde merged commit b00c026 into electron:main Jun 3, 2022
@release-clerk
Copy link

release-clerk bot commented Jun 3, 2022

Release Notes Persisted

Fixed a crash when loading a same-origin URL after a render process crash.

@trop
Copy link
Contributor

trop bot commented Jun 3, 2022

I have automatically backported this PR to "18-x-y", please check out #34430

@trop trop bot added the in-flight/18-x-y label Jun 3, 2022
@trop
Copy link
Contributor

trop bot commented Jun 3, 2022

I have automatically backported this PR to "19-x-y", please check out #34431

@trop trop bot removed the target/18-x-y label Jun 3, 2022
@trop
Copy link
Contributor

trop bot commented Jun 3, 2022

I have automatically backported this PR to "20-x-y", please check out #34432

@trop trop bot added merged/19-x-y and removed target/20-x-y labels Jun 3, 2022
@samuelmaddock samuelmaddock deleted the fix/renderer-crash-handling branch June 3, 2022 15:15
khalwa pushed a commit to solarwindscloud/electron that referenced this pull request Feb 22, 2023
* fix: crash when renderer process is reused

Could occur when a renderer crashes and the same-origin URL is loaded again
which leads to reusing the renderer process.

* test: renderer process crash recovery

* fix: handle case which leads to render frame DCHECK

* fix: lint
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
new-pr 🌱 PR opened in the last 24 hours semver/patch backwards-compatible bug fixes
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants