[Bug]: Crash in WebFrameMain::Connect() -> GetInterface -> GetInterfaceByName

[t57ser]

Preflight Checklist

• I have read the Contributing Guidelines for this project.
• I agree to follow the Code of Conduct that this project adheres to.
• I have searched the issue tracker for a bug report that matches the one I want to file, without success.

Electron Version

17, 18

What operating system are you using?

Windows

Operating System Version

Windows 10 19042.985

What arch are you using?

x64

Last Known Working Electron version

14

Expected Behavior

No crash

Actual Behavior

Electron crashes

This does not happen consistently but fairly often and can be reproduced in the app.
I have not been able yet to make a small/standalone reproducable example

Testcase Gist URL

No response

Additional Information

No response

[t57ser]

Some testing results:
15.0.0 -> working
16.0.0 -> working
16.2.3 -> working
17.0.0 -> crash
17.3.1 -> crash
17.4.1 -> crash
18.0.4 -> crash

[t57ser]

I can see that each time before the crash it seems like a renderer is crashing first and then 2-3s later electron crashes

[samuelmaddock]

Thanks for including the stacktrace! This seems to be occurring when a speculative RenderFrameHost is created upon navigating with webContents.loadURL.

Here we prevent emitting the "frame-created" event with speculative render frames. A potential fix would be to prevent calling WebFrameMain::Connect with speculative render frames.

electron/shell/browser/api/electron_api_web_contents.cc

Lines 1525 to 1539 in 6a1748d

	void WebContents::RenderFrameCreated(
	content::RenderFrameHost* render_frame_host) {
	HandleNewRenderFrame(render_frame_host);
	// RenderFrameCreated is called for speculative frames which may not be
	// used in certain cross-origin navigations. Invoking
	// RenderFrameHost::GetLifecycleState currently crashes when called for
	// speculative frames so we need to filter it out for now. Check
	// https://crbug.com/1183639 for details on when this can be removed.
	auto* rfh_impl =
	static_cast<content::RenderFrameHostImpl*>(render_frame_host);
	if (rfh_impl->lifecycle_state() ==
	content::RenderFrameHostImpl::LifecycleStateImpl::kSpeculative) {
	return;
	}

To write a reproducible test case, it will have something to do with cross-origin navigation.

[t57ser]

Thanks for the quick investigation, once the pull request is available I will give it a try.

[samuelmaddock]

Hey @t57ser. The PR I created should fix the issue, but I still was never able to reproduce the crash. Did you have any luck in reproducing a minimal case in Electron Fiddle or would you be open to it?

Could you maybe describe what happens in your app which leads up to the crash? It seems like you were able to reproduce it reliably.

[t57ser]

I am not 100% sure what causes it, but I can tell what fixed it.
At startup of the app, multiple windows are loaded with 3rd party apps, one of those seems to cause a crash (renderer crash) and afterwards electron crashes. I fixed it by not allowing loadURL in partitions that experienced a content crash.
I guess it is a combination of a renderer crashing and calling loadURL?
Maybe to note as well, the 3rd party app is only consistently crashing since v17. Probably something changed that is now causing the app to crash and has negative side effects

[samuelmaddock]

I guess it is a combination of a renderer crashing and calling loadURL?

This ended up being correct, thanks @t57ser. #34428 added tests for this. A slight delay was needed to reproduce the crash.