javascript debugging Debug.StepAction.step(In/Out/Next) - how to use?

[Zac Hansen]

I'm trying to support step in/out/next but can't figure out how to use them.

I see that I get an ExecutionState in my v8::Debug::EventDetails.  I grab that and then I try to call prepareStep on it, but I get a:

Check failed: isolate->debug()->CheckExecutionState(break_id)

runtime-debug.cc 1206:

RUNTIME_FUNCTION(Runtime_PrepareStep) {

  HandleScope scope(isolate);

  DCHECK(args.length() == 2);

  CONVERT_NUMBER_CHECKED(int, break_id, Int32, args[0]);

  CHECK(isolate->debug()->CheckExecutionState(break_id)); <==== HERE

I've got isolate/handle/(debug)context scopes set up when I try to make the call.   

Also, after I successfully call that, how do I execute the step?   Do I just resume execution by returning from the callback and it automatically does the step?   or do I have to call sometehing explicit to execute the step?

Thank you.

--Zac

[Ben Noordhuis]

On Tue, Oct 4, 2016 at 8:31 AM, Zac Hansen <xax...@gmail.com> wrote:
> I'm trying to support step in/out/next but can't figure out how to use them.
>
> I see that I get an ExecutionState in my v8::Debug::EventDetails. I grab
> that and then I try to call prepareStep on it, but I get a:
>
> Check failed: isolate->debug()->CheckExecutionState(break_id)
>
> runtime-debug.cc 1206:
>
> RUNTIME_FUNCTION(Runtime_PrepareStep) {
> HandleScope scope(isolate);
> DCHECK(args.length() == 2);
> CONVERT_NUMBER_CHECKED(int, break_id, Int32, args[0]);
> CHECK(isolate->debug()->CheckExecutionState(break_id)); <==== HERE
>
> I've got isolate/handle/(debug)context scopes set up when I try to make the
> call.

Hard to say what goes wrong. Do you check that the event is a Break
event? If that isn't it, please post your code. :-)

Try getting it working in JS using Debug.setListener() first before
porting it to C++; you'll save lots of time that way.

> Also, after I successfully call that, how do I execute the step? Do I just
> resume execution by returning from the callback and it automatically does
> the step? or do I have to call sometehing explicit to execute the step?

Just return.

[Zac Hansen]

Is there documentation on how to do any of this stuff?  setListener or otherwise?

--
--
v8-users mailing list
v8-u...@googlegroups.com
http://groups.google.com/group/v8-users
---
You received this message because you are subscribed to a topic in the Google Groups "v8-users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/v8-users/aXsjkboYVgk/unsubscribe.
To unsubscribe from this group and all its topics, send an email to v8-users+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Ben Noordhuis]

On Tue, Oct 4, 2016 at 10:29 PM, Zac Hansen <xax...@gmail.com> wrote:
> Is there documentation on how to do any of this stuff? setListener or
> otherwise?

V8 is a project in that long and rich OSS tradition of 'the source is
the documentation.'

[Zac Hansen]

the debugging portion seems to be much more poorly documented than the rest of the system -- which is impressive.

[Zac Hansen]

I'm really getting the feeling I'm not doing this debugging work right.   

I'm spending a lot of time "grepping" out values from the javascript objects in EventDetails into c++, then basically using printf to create some javascript code using those values to call into the debug.js code to do what I want.   

Is this a "good" way to do stuff or is there a better approach?

--Zac

[Ben Noordhuis]

On Wed, Oct 5, 2016 at 2:54 PM, Zac Hansen <xax...@gmail.com> wrote:
> I'm really getting the feeling I'm not doing this debugging work right.
>
> I'm spending a lot of time "grepping" out values from the javascript objects
> in EventDetails into c++, then basically using printf to create some
> javascript code using those values to call into the debug.js code to do what
> I want.
>
> Is this a "good" way to do stuff or is there a better approach?
>
> --Zac

If it helps, I pieced it together by reading src/debug and
src/runtime/runtime-debug.cc and going over the tests in
test/mjsunit/debug-*.js and test/cctest/test-debug.cc.

I mentioned it up-thread but putting together a working prototype in
JS first will save you oodles of time and frustration.

[Zac Hansen]

I wasn't keeping track of the correct execution context.. once I fixed that, things started working as expected.