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