electron: Renderer subprocess crash on method invocation.
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 an issue that matches the one I want to file, without success.
Issue Details
- Electron Version:
- 6.0.10
- Operating System:
- Windows 10 (1903)
- Last Known Working Electron version:
- 5.0.10
Expected Behavior
Invoking a method (defined in and provided by the main process) from the renderer process (attached to the global object in the preload script), should work and not crash the renderer process.
Actual Behavior
Invoking such method with simple arguments like a string or a simple object works, but invoking it with a complex nested object (no circular dependency and low in size) causes the renderer process to crash.
To Reproduce
Git Repo URL: https://github.com/flashd2n/electron-submit
$ git clone https://github.com/flashd2n/electron-submit.git
$ npm install
$ npm start
Additional Information
Starting the app will open a single window and it’s devtools console. The main process will pass to the renderer an object (reproduce) with a property (invoke) - a method which returns a success message. In the renderer’s preload script this object is assigned to the global window object. The spawned window has three buttons:
- Simple - invokes window.reproduce.invoke with a simple string and prints the result
- Medium - invokes window.reproduce.invoke with a medium in complexity object and prints the result
- Complex - invokes window.reproduce.invoke with a high in complex object and prints the result
Simple or Medium will print the success message the the window console, but Complex will crash subprocess and close the window - a crash message is displayed in the main process’s console.
This was tried in Electron:
- 5.0.10 - all invocations work.
- 6.0.10 - the complex invocation crashes the subprocess.
- 7.0.0-beta.4 - the complex invocation crashes the subprocess.
About this issue
- Original URL
- State: closed
- Created 5 years ago
- Reactions: 31
- Comments: 21 (13 by maintainers)
#21922 ought to resolve this, I hope! At least, to the extent that it ought to behave much closer to the pre-Mojo version vis-a-vis how the values are serialized under the hood. I tested @flashd2n’s repro with that patch applied and was able to successfully send the most nested object in that repro, which is ~10 levels deep.
@Slapbox do you have a repro? it may be that there are additional layers introduced by the
base::Valueserialization such that the depth-100 limit is reached for even a smaller object.Also, would you be able to try it out on the Electron 8 beta series? Electron 8 now uses the new Structured Clone-based IPC, so it should hopefully be able to handle much deeper objects.
Ok, cool, I’ll close this issue then as I believe it’s been resolved.
Okay @nornagon, I have done quite a bit more research, and I believe the issue is actually not the IPC calls, rather, Service Worker integration when
nodeIntegrationInWorker=true.I believe I hit the following issue, as disabling
nodeIntegrationInWorker(in an effort to minimize the application I packed up for you, of course, yay!) stabilized the application:https://stackoverflow.com/questions/59107643/how-can-i-register-a-service-worker-in-electron-when-node-integration-is-enabled
https://github.com/electron/electron/issues/19150
Please disregard for this issue. I initially had seen success doing stringification, but I think I had probably disabled the service worker integration somehow during my modifications (or was running in DEV mode, where SW is disabled by default.)
@nornagon Following your question to @Slapbox to test against Electron 8, I also encountered this issue with https://github.com/marktext/marktext/issues/1797 and building against 8.0.0 beta 4 saw the crash disappear.