Title: [196497] trunk/Source/_javascript_Core
- Revision
- 196497
- Author
- keith_mil...@apple.com
- Date
- 2016-02-12 12:44:44 -0800 (Fri, 12 Feb 2016)
Log Message
AdaptiveInferredPropertyValueWatchpoint can trigger a GC that frees its CodeBlock and thus itself
https://bugs.webkit.org/show_bug.cgi?id=154146
Reviewed by Filip Pizlo.
Consider the following: there is some CodeBlock, C, that is watching some object, O, with a
structure, S, for replacements. Also, suppose that C has no references anymore and is due to
be GCed. Now, when some new property is added to O, S will create a new structure S' and
fire its transition watchpoints. Since C is watching S for replacements it will attempt to
have its AdaptiveInferredPropertyValueWatchpoint relocate itself to S'. To do so, it needs
it allocate RareData on S'. This allocation may cause a GC, which frees C while still
executing its watchpoint handler. The solution to this is to defer GC while running
AdaptiveInferredPropertyValueWatchpointBase handlers.
* bytecode/AdaptiveInferredPropertyValueWatchpointBase.cpp:
(JSC::AdaptiveInferredPropertyValueWatchpointBase::fire):
Modified Paths
Diff
Modified: trunk/Source/_javascript_Core/ChangeLog (196496 => 196497)
--- trunk/Source/_javascript_Core/ChangeLog 2016-02-12 20:31:35 UTC (rev 196496)
+++ trunk/Source/_javascript_Core/ChangeLog 2016-02-12 20:44:44 UTC (rev 196497)
@@ -1,3 +1,22 @@
+2016-02-12 Keith Miller <keith_mil...@apple.com>
+
+ AdaptiveInferredPropertyValueWatchpoint can trigger a GC that frees its CodeBlock and thus itself
+ https://bugs.webkit.org/show_bug.cgi?id=154146
+
+ Reviewed by Filip Pizlo.
+
+ Consider the following: there is some CodeBlock, C, that is watching some object, O, with a
+ structure, S, for replacements. Also, suppose that C has no references anymore and is due to
+ be GCed. Now, when some new property is added to O, S will create a new structure S' and
+ fire its transition watchpoints. Since C is watching S for replacements it will attempt to
+ have its AdaptiveInferredPropertyValueWatchpoint relocate itself to S'. To do so, it needs
+ it allocate RareData on S'. This allocation may cause a GC, which frees C while still
+ executing its watchpoint handler. The solution to this is to defer GC while running
+ AdaptiveInferredPropertyValueWatchpointBase handlers.
+
+ * bytecode/AdaptiveInferredPropertyValueWatchpointBase.cpp:
+ (JSC::AdaptiveInferredPropertyValueWatchpointBase::fire):
+
2016-02-12 Gavin Barraclough <barraclo...@apple.com>
Separate out !allowsAccess path in JSDOMWindowCustom getOwnPropertySlot
Modified: trunk/Source/_javascript_Core/bytecode/AdaptiveInferredPropertyValueWatchpointBase.cpp (196496 => 196497)
--- trunk/Source/_javascript_Core/bytecode/AdaptiveInferredPropertyValueWatchpointBase.cpp 2016-02-12 20:31:35 UTC (rev 196496)
+++ trunk/Source/_javascript_Core/bytecode/AdaptiveInferredPropertyValueWatchpointBase.cpp 2016-02-12 20:44:44 UTC (rev 196497)
@@ -50,6 +50,10 @@
void AdaptiveInferredPropertyValueWatchpointBase::fire(const FireDetail& detail)
{
+ // We need to defer GC here otherwise we might trigger a GC that could destroy the owner
+ // CodeBlock. In particular, this can happen when we add rare data to a structure when
+ // we EnsureWatchability.
+ DeferGCForAWhile defer(*Heap::heap(m_key.object()));
// One of the watchpoints fired, but the other one didn't. Make sure that neither of them are
// in any set anymore. This simplifies things by allowing us to reinstall the watchpoints
// wherever from scratch.
_______________________________________________
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes
