Do not iterate stack handlers in SafeStackFrameIterator
authoryurys@chromium.org <yurys@chromium.org@ce2b1a6d-e550-0410-aec6-3dcde31c8c00>
Thu, 27 Jun 2013 09:28:11 +0000 (09:28 +0000)
committeryurys@chromium.org <yurys@chromium.org@ce2b1a6d-e550-0410-aec6-3dcde31c8c00>
Thu, 27 Jun 2013 09:28:11 +0000 (09:28 +0000)
commit4aeccdb23e418f5523e6bf9c71d80bed9be91d76
treee7d938664321e90cddd7338b7e386a9257d24e5b
parent98f3dab73b18dabbc703e24fc83e24653e1d486e
Do not iterate stack handlers in SafeStackFrameIterator

CPU profiler doesn't use stack handlers so there is no need to iterate through them while traversing stack. This change SafeStackFrameIterator always iterate only frames and removes checks corresponding to the handlers iteration.

The problem described in the bug occurred because of a false assumption in SafeStackFrameIterator that if Isolate::c_entry_fp is not NULL then the top frame on the stack is always a C++ frame. It is false because we may have entered JS code again, in which case JS_ENTRY code stub generated by JSEntryStub::GenerateBody() will save current c_entry_fp value but not reset it to NULL and after that it will create ENTRY stack frame and JS_ENTRY handler on the stack and put the latter into Isolate::handler(top). This means that if we start iterating from c_entry_fp frame and try to compare the frame's sp with Isolate::handler()->address() it will turn out that frame->sp() > handler->address() and the condition in SafeStackFrameIterator::CanIterateHandles is not held.

BUG=252097
R=loislo@chromium.org, svenpanne@chromium.org

Review URL: https://codereview.chromium.org/17589022

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15348 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
src/frames.cc
src/frames.h
test/cctest/test-cpu-profiler.cc