Title: [86960] trunk/Source/_javascript_Core
Revision
86960
Author
[email protected]
Date
2011-05-20 09:19:38 -0700 (Fri, 20 May 2011)

Log Message

2011-05-20  Oliver Hunt  <[email protected]>

        Reviewed by Sam Weinig.

        Interpreter uses wrong bytecode offset for determining exception handler
        https://bugs.webkit.org/show_bug.cgi?id=61191

        The bytecode offset given for the returnPC from the JIT is
        actually the offset for the start of the instruction triggering
        the call, whereas in the interpreter it is the actual return
        VPC.  This means if the next instruction following a call was
        in an exception region we would incorrectly redirect to its
        handler.  Long term we want to completely redo how exceptions
        are handled anyway so the simplest and lowest risk fix here is
        to simply subtract one from the return vPC so that we have an
        offset in the triggering instruction.

        It turns out this is caught by a couple of tests already.

        * interpreter/Interpreter.cpp:
        (JSC::Interpreter::unwindCallFrame):

Modified Paths

Diff

Modified: trunk/Source/_javascript_Core/ChangeLog (86959 => 86960)


--- trunk/Source/_javascript_Core/ChangeLog	2011-05-20 16:15:08 UTC (rev 86959)
+++ trunk/Source/_javascript_Core/ChangeLog	2011-05-20 16:19:38 UTC (rev 86960)
@@ -1,3 +1,25 @@
+2011-05-20  Oliver Hunt  <[email protected]>
+
+        Reviewed by Sam Weinig.
+
+        Interpreter uses wrong bytecode offset for determining exception handler
+        https://bugs.webkit.org/show_bug.cgi?id=61191
+
+        The bytecode offset given for the returnPC from the JIT is
+        actually the offset for the start of the instruction triggering
+        the call, whereas in the interpreter it is the actual return
+        VPC.  This means if the next instruction following a call was
+        in an exception region we would incorrectly redirect to its
+        handler.  Long term we want to completely redo how exceptions
+        are handled anyway so the simplest and lowest risk fix here is
+        to simply subtract one from the return vPC so that we have an
+        offset in the triggering instruction.
+
+        It turns out this is caught by a couple of tests already.
+
+        * interpreter/Interpreter.cpp:
+        (JSC::Interpreter::unwindCallFrame):
+
 2011-05-20  Xan Lopez  <[email protected]>
 
         Reviewed by Oliver Hunt.

Modified: trunk/Source/_javascript_Core/interpreter/Interpreter.cpp (86959 => 86960)


--- trunk/Source/_javascript_Core/interpreter/Interpreter.cpp	2011-05-20 16:15:08 UTC (rev 86959)
+++ trunk/Source/_javascript_Core/interpreter/Interpreter.cpp	2011-05-20 16:19:38 UTC (rev 86960)
@@ -578,15 +578,23 @@
         return false;
 
     codeBlock = callerFrame->codeBlock();
+    
+    // Because of how the JIT records call site->bytecode offset
+    // information the JIT reports the bytecodeOffset for the returnPC
+    // to be at the beginning of the opcode that has caused the call.
+    // In the interpreter we have an actual return address, which is
+    // the beginning of next instruction to execute. To get an offset
+    // inside the call instruction that triggered the exception we
+    // have to subtract 1.
 #if ENABLE(JIT) && ENABLE(INTERPRETER)
     if (callerFrame->globalData().canUseJIT())
         bytecodeOffset = codeBlock->bytecodeOffset(callFrame->returnPC());
     else
-        bytecodeOffset = codeBlock->bytecodeOffset(callFrame->returnVPC());
+        bytecodeOffset = codeBlock->bytecodeOffset(callFrame->returnVPC()) - 1;
 #elif ENABLE(JIT)
     bytecodeOffset = codeBlock->bytecodeOffset(callFrame->returnPC());
 #else
-    bytecodeOffset = codeBlock->bytecodeOffset(callFrame->returnVPC());
+    bytecodeOffset = codeBlock->bytecodeOffset(callFrame->returnVPC()) - 1;
 #endif
 
     callFrame = callerFrame;
_______________________________________________
webkit-changes mailing list
[email protected]
http://lists.webkit.org/mailman/listinfo.cgi/webkit-changes

Reply via email to