[Webkit-unassigned] [Bug 66571] Keep track of topCallFrame for Stack traces

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=66571





--- Comment #13 from Geoffrey Garen <ggaren at apple.com>  2011-08-22 17:36:59 PST ---
(In reply to comment #12)
> > > Source/JavaScriptCore/interpreter/Interpreter.cpp:711
> > >      CodeBlock* codeBlock = callFrame->codeBlock();
> > >      bool isInterrupt = false;
> > > +    callFrame->globalData().topCallFrame = callFrame;
> > 
> > Why does the first act of throwing an exception need to be to set topCallFrame? 
> 
> in throwException(), addErrorInfo() needs the updated callFrame to work properly. I update the topCallFrame before the first if statement to set it in case it branches.

If you saw cases where addErrorInfo() saw the wrong callFrame, perhaps they were caused by some of the cases of missing updates I listed. If you do the job right, addErrorInfo, like all C++ code, should always have a coherent view of topCallFrame.

> > On the other hand, I think you're missing an update of topCallFrame after you've thrown an exception and decided to return to a handler. You can put the update into unwindCallFrame().
> 
> If I only update the callFrame inside unwindCallFrame, my code would fail jsc-tests. As I mentioned before, addErrorInfo() needs the updated callFrame to work, and addErrorInfo() is called before unwindCallFrame()

The update at the top of Interpreter::throwException will not make topCallFrame correct after you've thrown an exception and decided to return to a handler. Consider this case:

(function () { try { (function() { throw "error"; })(); } catch(exception) { // topCallFrame is now wrong. } })();

topCallFrame needs to point to the callFrame of the exception handler, which can be zero or more frames up the stack from the frame that throws the exception.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.