Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: 80d2d35df69342302790e647b2d52bc66f1560a8
https://github.com/WebKit/WebKit/commit/80d2d35df69342302790e647b2d52bc66f1560a8
Author: Dan Hecht <[email protected]>
Date: 2026-03-04 (Wed, 04 Mar 2026)
Changed paths:
M Source/JavaScriptCore/heap/MarkedBlock.cpp
M Source/JavaScriptCore/heap/MarkedBlock.h
Log Message:
-----------
[JSC] Distinguish GC UAF crashes from general memory corruption crashes
https://bugs.webkit.org/show_bug.cgi?id=309122
rdar://171670183
Reviewed by Keith Miller.
When a MarkedBlock is not found in any VM's block set or directory,
that's a pretty good indication that the zeroed handle is due to the
MarkedBlock already being freed back to the system. The most likely
reason for that is that a GC client created a dangling reference
scenario where the reference is traversed during marking but was not
kept alive in a previous cycle due the object not being reachable
from roots or a missing write barrier.
Add a crash location to give this likely root cause and action hint.
Testing: __XPC_JSC_markedBlockDumpInfoCount=16389 __XPC_JSC_useConcurrentGC=0
run-safari
and checked resulting crash log
* Source/JavaScriptCore/heap/MarkedBlock.cpp:
(JSC::MarkedBlock::setupTestForDumpInfoAndCrash):
(JSC::MarkedBlock::aboutToMarkSlow):
(JSC::crashDueToGarbageCollectorClientDanglingReference_CheckRootsAndBarriers):
(JSC::MarkedBlock::dumpInfoAndCrashForInvalidHandleV2):
(JSC::MarkedBlock::analyzeInvalidHandleAndCrash):
* Source/JavaScriptCore/heap/MarkedBlock.h:
Canonical link: https://commits.webkit.org/308669@main
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
