Skip to content

PolymorphicCallNode should unchain itself first in unlink https://bug…#1665

Open
aoikonomopoulos wants to merge 1 commit intoWebPlatformForEmbedded:wpe-2.38from
aoikonomopoulos:wpe-2.38-backport-PolymorphicCallNode-should-unchain
Open

PolymorphicCallNode should unchain itself first in unlink https://bug…#1665
aoikonomopoulos wants to merge 1 commit intoWebPlatformForEmbedded:wpe-2.38from
aoikonomopoulos:wpe-2.38-backport-PolymorphicCallNode-should-unchain

Conversation

@aoikonomopoulos
Copy link
Copy Markdown

@aoikonomopoulos aoikonomopoulos commented May 5, 2026

…s.webkit.org/show_bug.cgi?id=265475 rdar://118893186

Reviewed by Mark Lam.

PolymorphicCallNode::unlinkImpl calls m_callLinkInfo->unlink. But it is possible that this CallLinkInfo is holding PolymorphicCallNode's owner stub and it may clear stub. Previously, we are always deferring this stub destruction until JITStubRoutineSet destroys it. But now, it is possible that they get deleted immediately when owner CodeBlock is dead. This means that after calling m_callLinkInfo->unlink, it is possible that PolymorphicCallNode |this| is already destroyed.

This patch reorders unlink's operation in PolymorphicCallNode so that we first unlink it from linked-list. This is OK since we are not expecting that this is in the linked-list in unlink calls. So after m_callLinkInfo->unlink, we no longer touch anything in PolymorphicCallNode.

  • Source/JavaScriptCore/jit/PolymorphicCallStubRoutine.cpp: (JSC::PolymorphicCallNode::unlinkImpl):

Canonical link: https://commits.webkit.org/271246@main

Pull Request Template

File a Bug

All changes should be associated with a bug. The WebKit project is currently using Bugzilla as our bug tracker. Note that multiple changes may be associated with a single bug.

Provided Tooling

The WebKit Project strongly recommends contributors use Tools/Scripts/git-webkit to generate pull requests. See Setup and Contributing Code for how to do this.

Template

If a contributor wishes to file a pull request manually, the template is below. Manually-filed pull requests should contain their commit message as the pull request description, and their commit message should be formatted like the template below.

Additionally, the pull request should be mentioned on Bugzilla, labels applied to the pull request matching the component and version of the Bugzilla associated with the pull request and the pull request assigned to its author.

< bug title >
https://bugs.webkit.org/show_bug.cgi?id=#####

Reviewed by NOBODY (OOPS!).

Explanation of why this fixes the bug (OOPS!).

* path/changed.ext:
(function):
(class.function):

06a5eaf

Build-Tests Layout-Tests
loading 🛠 wpe-238-amd64-build loading 🧪 wpe-238-amd64-layout
loading 🛠 wpe-238-arm32-build loading 🧪 wpe-238-arm32-layout
⏳ 🛠 wpe-246-amd64-build ⏳ 🧪 wpe-246-amd64-layout

…s.webkit.org/show_bug.cgi?id=265475 rdar://118893186

Reviewed by Mark Lam.

PolymorphicCallNode::unlinkImpl calls m_callLinkInfo->unlink. But it is possible that this CallLinkInfo is
holding PolymorphicCallNode's owner stub and it may clear stub. Previously, we are always deferring this stub
destruction until JITStubRoutineSet destroys it. But now, it is possible that they get deleted immediately
when owner CodeBlock is dead. This means that after calling m_callLinkInfo->unlink, it is possible that PolymorphicCallNode |this|
is already destroyed.

This patch reorders unlink's operation in PolymorphicCallNode so that we first unlink it from linked-list.
This is OK since we are not expecting that this is in the linked-list in unlink calls. So after m_callLinkInfo->unlink,
we no longer touch anything in PolymorphicCallNode.

* Source/JavaScriptCore/jit/PolymorphicCallStubRoutine.cpp:
(JSC::PolymorphicCallNode::unlinkImpl):

Canonical link: https://commits.webkit.org/271246@main
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Development

Successfully merging this pull request may close these issues.

2 participants