Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: b3de1ab9ff924b487d8f003b162195fbdf37a8eb
https://github.com/WebKit/WebKit/commit/b3de1ab9ff924b487d8f003b162195fbdf37a8eb
Author: Razvan Caliman <[email protected]>
Date: 2025-03-12 (Wed, 12 Mar 2025)
Changed paths:
M Source/JavaScriptCore/inspector/remote/RemoteConnectionToTarget.cpp
M
Source/JavaScriptCore/inspector/remote/cocoa/RemoteConnectionToTargetCocoa.mm
M Source/JavaScriptCore/runtime/JSGlobalObjectDebuggable.cpp
Log Message:
-----------
WebInspector: window close causes host-app crash under
RemoteInspector::listingForInspectionTarget()
https://bugs.webkit.org/show_bug.cgi?id=289504
rdar://146650431
Reviewed by BJ Burg.
Calling `JSGlobalObjectDebuggable::name()` on a remote inspection target (aka
debuggable)
which no longer has an associated `JSGlobalObject` causes a crash because
it attempts to get the name from that `JSGlobalObject`.
The situation can occur when a Web Inspector window is the only thing that keeps
a `JSGlobalObject` alive via the intentional strong reference created in
`JSGlobalObjectInspectorController::connectFrontend()`.
When inspection is terminated via `RemoteConnectionToTarget::close()`,
the frontend is disconnected
(`JSGlobalObjectInspectorController::disconnectFrontend`)
and the strong reference is removed so the `JSGlobalObject` can be destroyed.
Its destructor removes the reference from the debuggable
(`JSGlobalObjectDebuggable::globalObjectDestroyed()`)
which should allow for the `JSGlobalObjectDebuggable` to be itself destroyed
(`RemoteControllableTarget::~RemoteControllableTarget()`).
This would remove it from the list of targets tracked by `RemoteInspector`.
But the RefPtr to the target in `RemoteConnectionToTarget::close()` prevents
that destruction
so the call to `RemoteInspector::singleton().updateTargetListing()` proceeds
with a still alive
`JSGlobalObjectDebuggable` that no longer has an associated `JSGlobalObject`.
This patch moves the call to
`RemoteInspector::singleton().updateTargetListing()` outside
the block scope that keeps the target alive due to the RefPtr.
The call is already using a cached target identifier and attempts to match a
target tracked by `RemoteInspector`.
If there is no match (the desired scenario because the target was allowed to be
destroyed),
it returns early and prevents the condition for the crash.
* Source/JavaScriptCore/inspector/remote/cocoa/RemoteConnectionToTargetCocoa.mm:
(Inspector::RemoteConnectionToTarget::close):
* Source/JavaScriptCore/inspector/remote/RemoteConnectionToTarget.cpp:
(Inspector::RemoteConnectionToTarget::close):
Align the implementation with Cocoa version to prevent the RefPtr keeping the
debuggable alive.
* Source/JavaScriptCore/runtime/JSGlobalObjectDebuggable.cpp:
(JSC::JSGlobalObjectDebuggable::name const):
Ensure a JSGlobalObject exists before accessing its name.
Canonical link: https://commits.webkit.org/292048@main
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
_______________________________________________
webkit-changes mailing list
[email protected]
https://lists.webkit.org/mailman/listinfo/webkit-changes
