Title: [206643] trunk/Source/_javascript_Core
Revision
206643
Author
[email protected]
Date
2016-09-30 11:15:38 -0700 (Fri, 30 Sep 2016)

Log Message

Use topVMEntryFrame to determine whether to skip the re-throw of a simulated throw.
https://bugs.webkit.org/show_bug.cgi?id=162793

Reviewed by Saam Barati.

Change the ThrowScope destructor to use topVMEntryFrame (instead of topCallFrame)
in the determination of whether to skip the re-throw of a simulated throw.  This
is needed because the topCallFrame is not updated in operationConstructArityCheck()
(and does not need to be), whereas topVMEntryFrame is always updated properly.
Hence, we should just switch to using the more reliable topVMEntryFrame instead.

This issue was discovered by existing JSC tests when exception check validation
is enabled.

* runtime/ThrowScope.cpp:
(JSC::ThrowScope::~ThrowScope):

Modified Paths

Diff

Modified: trunk/Source/_javascript_Core/ChangeLog (206642 => 206643)


--- trunk/Source/_javascript_Core/ChangeLog	2016-09-30 17:02:46 UTC (rev 206642)
+++ trunk/Source/_javascript_Core/ChangeLog	2016-09-30 18:15:38 UTC (rev 206643)
@@ -1,3 +1,22 @@
+2016-09-30  Mark Lam  <[email protected]>
+
+        Use topVMEntryFrame to determine whether to skip the re-throw of a simulated throw.
+        https://bugs.webkit.org/show_bug.cgi?id=162793
+
+        Reviewed by Saam Barati.
+
+        Change the ThrowScope destructor to use topVMEntryFrame (instead of topCallFrame)
+        in the determination of whether to skip the re-throw of a simulated throw.  This
+        is needed because the topCallFrame is not updated in operationConstructArityCheck()
+        (and does not need to be), whereas topVMEntryFrame is always updated properly.
+        Hence, we should just switch to using the more reliable topVMEntryFrame instead.
+
+        This issue was discovered by existing JSC tests when exception check validation
+        is enabled.
+
+        * runtime/ThrowScope.cpp:
+        (JSC::ThrowScope::~ThrowScope):
+
 2016-09-30  Filip Pizlo  <[email protected]>
 
         64-bit LLInt needs to have a concurrency-aware barrier

Modified: trunk/Source/_javascript_Core/runtime/ThrowScope.cpp (206642 => 206643)


--- trunk/Source/_javascript_Core/runtime/ThrowScope.cpp	2016-09-30 17:02:46 UTC (rev 206642)
+++ trunk/Source/_javascript_Core/runtime/ThrowScope.cpp	2016-09-30 18:15:38 UTC (rev 206643)
@@ -57,13 +57,13 @@
 
     bool willBeHandleByLLIntOrJIT = false;
     void* previousScope = m_previousScope;
-    void* topCallFrame = m_vm.topCallFrame;
-    
-    // If the topCallFrame was pushed on the stack after the previousScope was instantiated,
+    void* topVMEntryFrame = m_vm.topVMEntryFrame;
+
+    // If the topVMEntryFrame was pushed on the stack after the previousScope was instantiated,
     // then this throwScope will be returning to LLINT or JIT code that always do an exception
     // check. In that case, skip the simulated throw because the LLInt and JIT will be
     // checking for the exception their own way instead of calling ThrowScope::exception().
-    if (topCallFrame && previousScope > topCallFrame)
+    if (topVMEntryFrame && previousScope > topVMEntryFrame)
         willBeHandleByLLIntOrJIT = true;
     
     if (!willBeHandleByLLIntOrJIT)
_______________________________________________
webkit-changes mailing list
[email protected]
https://lists.webkit.org/mailman/listinfo/webkit-changes

Reply via email to