V8 built-in debugger agent - how to activate?

[ondras]

Hi,

I am a bit confused regarding the built-in V8 debugger service. If I
am not mistaken, every V8 implementation contains a debugging server,
which can provide debugging data to a client via the JSON debugger
protocol. However, how can one activate/enable this service? Or am I
completely wrong on this one?


Thanks a lot for assistance,
Ondrej

[Søren Gjesse]

V8 have got a remote debugger service which can be activated through the debugger API v8::Debug::EnableAgent(). This will start a TCP/IP listener on the port passed. To debug you then need some application which can talk the debugger protocol - D8 can do that. To try it out you can use D8 as both the debugger and the embedding application hosting JavaScript to be debugged.

Run

$ ./d8 --debugger-agent

to start D8 with the debugger agent enabled, and run

$ ./d8 --remote-debugger

to connect the second D8 as the remote debugger to the first.

In the first D8 type the statement 'debugger' and you will see control reaches the debugger (causing an uncaught exception will also do that).

The remote debugger part of D8 is a bit rough and sometimes the prompt 'dbg>' is not displayed. Also there is currently no way to break into running JavaScript.

The debugger protocol is documented on http://code.google.com/p/v8/wiki/DebuggerProtocol. When using the debugger agent the JSON messages are wrapped with a simple HTTP like header.

[Ondrej Zara]

Hi Soren,

thanks for a perfectly prompt response. You have given me basically all the information I requested, I have only one little question - is it possible to initiate the v8::Debug::EnableAgent() via a built-in V8 command line argument (e.g. without any application support)? I know that there are some V8 command line switches (BTW, are these documented anywhere?) and I thought that some of them can enable the agent...


Thanks,
Ondrej

2009/9/4 Søren Gjesse <sgj...@chromium.org>

[Søren Gjesse]

I am afraid not. The --debugger-agent is a D8 specific flag which is not reacted upon when passed to the V8 engine.

If you pass --help to either the sample shell or D8 you will get a list of all flags. They are defined in src/flag-definitions.h.

Regards,

Søren

[Ryan Dahl]

Hi Søren,

If you receive a message in the DebuggerAgent and your main thread is
not immediately executing javascript but idling in select(), how can
you give control back to V8 to handle the message? It seems there
should be some way to poll the agent to handle received messages.

Am I correct in my reading that the while(true) loop body in
Debugger::NotifyMessageHandler() would be such a poll function if the
Wait()s were removed?

ry

[Søren Gjesse]

Hi Ryan

The loop in Debugger::NotifyMessageHandler() will not be activated until there is an actual debugger event happening. E.g. when a break point is hit Debugger::NotifyMessageHandler() will run to process the debug messages while at the break point until a continue message is received and V8 execution continues. In this loop it is possible to have callbacks to the embedding application at specific intervals as having the debugger event block the V8 thread might disrupt the embedding application. In Chrome this mechanism is used to keep parts of the message pump running while the renderer thread is otherwise blocked sitting a V8 break. This callback can be activated using SetHostDispatchHandler() in the V8 debugger API.

However it looks as if you are looking for the opposite that is a callback when a debug message is received and the embedding application needs to enter V8 to process these messages. You could try to have your select() call time out every 100ms or so and call an empty JavaScript function to simulate such a callback. If we where to put in such a callback it would be called from the debugger agent thread and the embedding application would then have to marshal that into a call into V8 from it's V8 thread.

You will also have to enable the flag --debugger-auto-break for V8 to generate an automatic break for processing debug messages.

Regards,

Søren

[Ryan Dahl]

2009/10/7 Søren Gjesse <sgj...@chromium.org>:

>
> However it looks as if you are looking for the opposite that is a callback
> when a debug message is received and the embedding application needs to
> enter V8 to process these messages. You could try to have your select() call
> time out every 100ms or so and call an empty JavaScript function to simulate
> such a callback. If we where to put in such a callback it would be called
> from the debugger agent thread and the embedding application would then have
> to marshal that into a call into V8 from it's V8 thread.
> You will also have to enable the flag --debugger-auto-break for V8 to
> generate an automatic break for processing debug messages.

Is it possible to be notified (via callback) outside of my main thread
(from the DebuggerAgent thread) about received messages? I would like
to use such a callback to write a byte to a pipe to wake up my
select(), this would avoid polling every 100 ms.

Thank you, ry

[Ryan Dahl]

Hi Søren,

I'm began a little patch to give such a wake-up callback (attached).
Is this something you all would accept?

It adds a new public function v8::Debug::Poll() which is to be called
from the main thread occasionally. It also adds an optional third
argument to v8::Debug::EnableAgent() which is a callback. The callback
(called "WantPollHandler") is executed from the Agent thread. The user
can use that callback to wake up the main thread to enter V8 (by
calling Poll()).

The patch currently untested, but I can probably put a unit test
together using the Semaphore's Signal() and Wait()

ry

[Søren Gjesse]

Hi Ryan,

After our discussion yesterday I have been working on a similar patch using an additional debugger API function SetDebugMessageDispatchHandler(DebugMessageDispatchHandler handler) instead of an additional parameter to EnableAgent, as it might be useful when not using the agent. I don't think the Poll() API is required as using option --debugger-auto-break and calling an empty JavaScript function should work the same. However this callback needs to be handled with care as it should not be used to enter V8 when receiving messages for processing in an active break. In your setting where you will just ensure the main thread is no longer sitting in select() it should be fine though.

You are most welcome to continue working on this as it will be easier for you to test it in a real application. Adding a test to test-debug.cc which checks that the callback is called when enabled is a good thing as well.

I have attached my patch which mainly differs in the naming.

Regards,

Søren