mirror of
https://github.com/electron/electron.git
synced 2026-10-28 11:44:46 +08:00
* fix: close the utilityProcess port before its descriptor is destroyed A UtilityProcessWrapper that is still alive when the heap is torn down at exit, for example one whose child had not finished launching when ElectronBrowserMainParts shut the others down, was destroyed with its postMessage port still lent to the mojo::Connector. Debug and sanitizer builds then hit DCHECK(handle_.is_valid()) in MessagePortDescriptor::Reset(). Move the connector and port descriptor onto a NativePeer. Its TearDownNative() takes the handle back and resets the descriptor, so the port is closed at MicrotasksRunner shutdown or after collection, never during cppgc sweeping. The exit-time order (dispatch pending messages, close the port, emit 'exit') is unchanged. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01LPMvJBQiyP6b7QjatACmnS * fix: close the utilityProcess port in the destructor and shut down launching wrappers Per review, replace the PortLifecycle native peer with a smaller fix: - ~UtilityProcessWrapper closes the connector port and any stdio read fds not yet handed to JS. Both are non-GC members, so this is allowed during cppgc sweeping, and it fixes the DCHECK in MessagePortDescriptor::Reset() for a wrapper still alive at heap teardown. - Bind the connector error handler with base::Unretained: the connector is owned by the wrapper and destroying it cancels the handler. - Drop the connector_->is_valid() check in CloseConnectorPort(); GiveDisentangledHandle() replaces an invalid handle with a dangling one, so the port is always reset. - Track wrappers from construction instead of from launch, and add UtilityProcessWrapper::ShutdownAll(), so PostMainMessageLoopRun() also shuts down wrappers whose child is still launching before Node.js stops. FromProcessId() ignores a null pid. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01LPMvJBQiyP6b7QjatACmnS --------- Co-authored-by: Claude <noreply@anthropic.com>