| OLD | NEW |
|---|
| (Empty) |
| 1 # Introduction | |
| 2 | |
| 3 V8 has support for debugging the JavaScript code running in it. There are two AP
I's for this a function based API using JavaScript objects and a message based A
PI using a JSON based protocol. The function based API can be used by an in-proc
ess debugger agent, whereas the message based API can be used out of process as
well. | |
| 4 **> The message based API is no longer maintained. Please ask in v8-users@google
groups.com if you want to attach a debugger to the run-time.** | |
| 5 | |
| 6 The debugger protocol is based on [JSON](http://www.json.org/)). Each protocol p
acket is defined in terms of JSON and is transmitted as a string value. All pack
ets have two basic elements `seq` and `type`. | |
| 7 | |
| 8 ``` | |
| 9 { "seq" : <number>, | |
| 10 "type" : <type>, | |
| 11 ... | |
| 12 } | |
| 13 ``` | |
| 14 | |
| 15 The element `seq` holds the sequence number of the packet. And element type is t
he type of the packet. The type is a string value with one of the following valu
es `"request"`, `"response"` or `"event"`. | |
| 16 | |
| 17 A `"request"` packet has the following structure: | |
| 18 | |
| 19 ``` | |
| 20 { "seq" : <number>, | |
| 21 "type" : "request", | |
| 22 "command" : <command> | |
| 23 "arguments" : ... | |
| 24 } | |
| 25 ``` | |
| 26 | |
| 27 A `"response"` packet has the following structure. If `success` is true `body` w
ill contain the response data. If `success` is false `message` will contain an e
rror message. | |
| 28 | |
| 29 ``` | |
| 30 { "seq" : <number>, | |
| 31 "type" : "response", | |
| 32 "request_seq" : <number>, | |
| 33 "command" : <command> | |
| 34 "body" : ... | |
| 35 "running" : <is the VM running after sending this response> | |
| 36 "success" : <boolean indicating success> | |
| 37 "message" : <if command failed this property contains an error message> | |
| 38 } | |
| 39 ``` | |
| 40 | |
| 41 An `"event"` packet has the following structure: | |
| 42 | |
| 43 ``` | |
| 44 { "seq" : <number>, | |
| 45 "type" : "event", | |
| 46 "event" : <event name> | |
| 47 body : ... | |
| 48 } | |
| 49 ``` | |
| 50 | |
| 51 # Request/response pairs | |
| 52 | |
| 53 ## Request `continue` | |
| 54 | |
| 55 The request `continue` is a request from the debugger to start the VM running ag
ain. As part of the `continue` request the debugger can specify if it wants the
VM to perform a single step action. | |
| 56 | |
| 57 ``` | |
| 58 { "seq" : <number>, | |
| 59 "type" : "request", | |
| 60 "command" : "continue", | |
| 61 "arguments" : { "stepaction" : <"in", "next" or "out">, | |
| 62 "stepcount" : <number of steps (default 1)> | |
| 63 } | |
| 64 } | |
| 65 ``` | |
| 66 | |
| 67 In the response the property `running` will always be true as the VM will be run
ning after executing the `continue` command. If a single step action is requeste
d the VM will respond with a `break` event after running the step. | |
| 68 | |
| 69 ``` | |
| 70 { "seq" : <number>, | |
| 71 "type" : "response", | |
| 72 "request_seq" : <number>, | |
| 73 "command" : "continue", | |
| 74 "running" : true | |
| 75 "success" : true | |
| 76 } | |
| 77 ``` | |
| 78 | |
| 79 | |
| 80 Here are a couple of examples. | |
| 81 | |
| 82 ``` | |
| 83 {"seq":117,"type":"request","command":"continue"} | |
| 84 {"seq":118,"type":"request","command":"continue","arguments":{"stepaction":"out"
}} | |
| 85 {"seq":119,"type":"request","command":"continue","arguments":{"stepaction":"next
","stepcount":5}} | |
| 86 ``` | |
| 87 | |
| 88 ## Request `evaluate` | |
| 89 | |
| 90 The request `evaluate` is used to evaluate an expression. The body of the result
is as described in response object serialization below. | |
| 91 | |
| 92 ``` | |
| 93 { "seq" : <number>, | |
| 94 "type" : "request", | |
| 95 "command" : "evaluate", | |
| 96 "arguments" : { "expression" : <expression to evaluate>, | |
| 97 "frame" : <number>, | |
| 98 "global" : <boolean>, | |
| 99 "disable_break" : <boolean>, | |
| 100 "additional_context" : [ | |
| 101 { "name" : <name1>, "handle" : <handle1> }, | |
| 102 { "name" : <name2>, "handle" : <handle2> }, | |
| 103 ... | |
| 104 ] | |
| 105 } | |
| 106 } | |
| 107 ``` | |
| 108 | |
| 109 Optional argument `additional_context` specifies handles that will be visible fr
om the expression under corresponding names (see example below). | |
| 110 | |
| 111 Response: | |
| 112 | |
| 113 ``` | |
| 114 { "seq" : <number>, | |
| 115 "type" : "response", | |
| 116 "request_seq" : <number>, | |
| 117 "command" : "evaluate", | |
| 118 "body" : ... | |
| 119 "running" : <is the VM running after sending this response> | |
| 120 "success" : true | |
| 121 } | |
| 122 ``` | |
| 123 | |
| 124 Here are a couple of examples. | |
| 125 | |
| 126 ``` | |
| 127 {"seq":117,"type":"request","command":"evaluate","arguments":{"expression":"1+2"
}} | |
| 128 {"seq":118,"type":"request","command":"evaluate","arguments":{"expression":"a()"
,"frame":3,"disable_break":false}} | |
| 129 {"seq":119,"type":"request","command":"evaluate","arguments":{"expression":"[o.a
,o.b,o.c]","global":true,"disable_break":true}} | |
| 130 {"seq":120,"type":"request","command":"evaluate","arguments":{"expression":"obj.
toString()", "additional_context": [{ "name":"obj","handle":25 }] }} | |
| 131 ``` | |
| 132 | |
| 133 ## Request `lookup` | |
| 134 | |
| 135 The request `lookup` is used to lookup objects based on their handle. The indivi
dual array elements of the body of the result is as described in response object
serialization below. | |
| 136 | |
| 137 ``` | |
| 138 { "seq" : <number>, | |
| 139 "type" : "request", | |
| 140 "command" : "lookup", | |
| 141 "arguments" : { "handles" : <array of handles>, | |
| 142 "includeSource" : <boolean indicating whether the source will
be included when script objects are returned>, | |
| 143 } | |
| 144 } | |
| 145 ``` | |
| 146 | |
| 147 Response: | |
| 148 | |
| 149 ``` | |
| 150 { "seq" : <number>, | |
| 151 "type" : "response", | |
| 152 "request_seq" : <number>, | |
| 153 "command" : "lookup", | |
| 154 "body" : <array of serialized objects indexed using their handle> | |
| 155 "running" : <is the VM running after sending this response> | |
| 156 "success" : true | |
| 157 } | |
| 158 ``` | |
| 159 | |
| 160 Here are a couple of examples. | |
| 161 | |
| 162 ``` | |
| 163 {"seq":117,"type":"request","command":"lookup","arguments":{"handles":"[1]"}} | |
| 164 {"seq":118,"type":"request","command":"lookup","arguments":{"handles":"[7,12]"}} | |
| 165 ``` | |
| 166 | |
| 167 ## Request `backtrace` | |
| 168 | |
| 169 The request `backtrace` returns a backtrace (or stacktrace) from the current exe
cution state. When issuing a request a range of frames can be supplied. The top
frame is frame number 0. If no frame range is supplied data for 10 frames will b
e returned. | |
| 170 | |
| 171 ``` | |
| 172 { "seq" : <number>, | |
| 173 "type" : "request", | |
| 174 "command" : "backtrace", | |
| 175 "arguments" : { "fromFrame" : <number> | |
| 176 "toFrame" : <number> | |
| 177 "bottom" : <boolean, set to true if the bottom of the stack is
requested> | |
| 178 } | |
| 179 } | |
| 180 ``` | |
| 181 | |
| 182 The response contains the frame data together with the actual frames returned an
d the toalt frame count. | |
| 183 | |
| 184 ``` | |
| 185 { "seq" : <number>, | |
| 186 "type" : "response", | |
| 187 "request_seq" : <number>, | |
| 188 "command" : "backtrace", | |
| 189 "body" : { "fromFrame" : <number> | |
| 190 "toFrame" : <number> | |
| 191 "totalFrames" : <number> | |
| 192 "frames" : <array of frames - see frame request for details> | |
| 193 } | |
| 194 "running" : <is the VM running after sending this response> | |
| 195 "success" : true | |
| 196 } | |
| 197 ``` | |
| 198 | |
| 199 If there are no stack frames the result body only contains `totalFrames` with a
value of `0`. When an exception event is generated due to compilation failures i
t is possible that there are no stack frames. | |
| 200 | |
| 201 Here are a couple of examples. | |
| 202 | |
| 203 ``` | |
| 204 {"seq":117,"type":"request","command":"backtrace"} | |
| 205 {"seq":118,"type":"request","command":"backtrace","arguments":{"toFrame":2}} | |
| 206 {"seq":119,"type":"request","command":"backtrace","arguments":{"fromFrame":0,"to
Frame":9}} | |
| 207 ``` | |
| 208 | |
| 209 ## Request `frame` | |
| 210 | |
| 211 The request frame selects a new selected frame and returns information for that.
If no frame number is specified the selected frame is returned. | |
| 212 | |
| 213 ``` | |
| 214 { "seq" : <number>, | |
| 215 "type" : "request", | |
| 216 "command" : "frame", | |
| 217 "arguments" : { "number" : <frame number> | |
| 218 } | |
| 219 } | |
| 220 ``` | |
| 221 | |
| 222 Response: | |
| 223 | |
| 224 ``` | |
| 225 { "seq" : <number>, | |
| 226 "type" : "response", | |
| 227 "request_seq" : <number>, | |
| 228 "command" : "frame", | |
| 229 "body" : { "index" : <frame number>, | |
| 230 "receiver" : <frame receiver>, | |
| 231 "func" : <function invoked>, | |
| 232 "script" : <script for the function>, | |
| 233 "constructCall" : <boolean indicating whether the function
was called as constructor>, | |
| 234 "debuggerFrame" : <boolean indicating whether this is an in
ternal debugger frame>, | |
| 235 "arguments" : [ { name: <name of the argument - missing
of anonymous argument>, | |
| 236 value: <value of the argument> | |
| 237 }, | |
| 238 ... <the array contains all the argumen
ts> | |
| 239 ], | |
| 240 "locals" : [ { name: <name of the local variable>, | |
| 241 value: <value of the local variable> | |
| 242 }, | |
| 243 ... <the array contains all the locals> | |
| 244 ], | |
| 245 "position" : <source position>, | |
| 246 "line" : <source line>, | |
| 247 "column" : <source column within the line>, | |
| 248 "sourceLineText" : <text for current source line>, | |
| 249 "scopes" : [ <array of scopes, see scope request bel
ow for format> ], | |
| 250 | |
| 251 } | |
| 252 "running" : <is the VM running after sending this response> | |
| 253 "success" : true | |
| 254 } | |
| 255 ``` | |
| 256 | |
| 257 Here are a couple of examples. | |
| 258 | |
| 259 ``` | |
| 260 {"seq":117,"type":"request","command":"frame"} | |
| 261 {"seq":118,"type":"request","command":"frame","arguments":{"number":1}} | |
| 262 ``` | |
| 263 | |
| 264 ## Request `scope` | |
| 265 | |
| 266 The request scope returns information on a givne scope for a givne frame. If no
frame number is specified the selected frame is used. | |
| 267 | |
| 268 ``` | |
| 269 { "seq" : <number>, | |
| 270 "type" : "request", | |
| 271 "command" : "scope", | |
| 272 "arguments" : { "number" : <scope number> | |
| 273 "frameNumber" : <frame number, optional uses selected frame if
missing> | |
| 274 } | |
| 275 } | |
| 276 ``` | |
| 277 | |
| 278 Response: | |
| 279 | |
| 280 ``` | |
| 281 { "seq" : <number>, | |
| 282 "type" : "response", | |
| 283 "request_seq" : <number>, | |
| 284 "command" : "scope", | |
| 285 "body" : { "index" : <index of this scope in the scope chain. Inde
x 0 is the top scope | |
| 286 and the global scope will always have the hi
ghest index for a | |
| 287 frame>, | |
| 288 "frameIndex" : <index of the frame>, | |
| 289 "type" : <type of the scope: | |
| 290 0: Global | |
| 291 1: Local | |
| 292 2: With | |
| 293 3: Closure | |
| 294 4: Catch >, | |
| 295 "object" : <the scope object defining the content of the
scope. | |
| 296 For local and closure scopes this is transie
nt objects, | |
| 297 which has a negative handle value> | |
| 298 } | |
| 299 "running" : <is the VM running after sending this response> | |
| 300 "success" : true | |
| 301 } | |
| 302 ``` | |
| 303 | |
| 304 Here are a couple of examples. | |
| 305 | |
| 306 ``` | |
| 307 {"seq":117,"type":"request","command":"scope"} | |
| 308 {"seq":118,"type":"request","command":"scope","arguments":{"frameNumber":1,"numb
er":1}} | |
| 309 ``` | |
| 310 | |
| 311 ## Request `scopes` | |
| 312 | |
| 313 The request scopes returns all the scopes for a given frame. If no frame number
is specified the selected frame is returned. | |
| 314 | |
| 315 ``` | |
| 316 { "seq" : <number>, | |
| 317 "type" : "request", | |
| 318 "command" : "scopes", | |
| 319 "arguments" : { "frameNumber" : <frame number, optional uses selected frame if
missing> | |
| 320 } | |
| 321 } | |
| 322 ``` | |
| 323 | |
| 324 Response: | |
| 325 | |
| 326 ``` | |
| 327 { "seq" : <number>, | |
| 328 "type" : "response", | |
| 329 "request_seq" : <number>, | |
| 330 "command" : "scopes", | |
| 331 "body" : { "fromScope" : <number of first scope in response>, | |
| 332 "toScope" : <number of last scope in response>, | |
| 333 "totalScopes" : <total number of scopes for this frame>, | |
| 334 "scopes" : [ <array of scopes, see scope request above for f
ormat> ], | |
| 335 } | |
| 336 "running" : <is the VM running after sending this response> | |
| 337 "success" : true | |
| 338 } | |
| 339 ``` | |
| 340 | |
| 341 Here are a couple of examples. | |
| 342 | |
| 343 ``` | |
| 344 {"seq":117,"type":"request","command":"scopes"} | |
| 345 {"seq":118,"type":"request","command":"scopes","arguments":{"frameNumber":1}} | |
| 346 ``` | |
| 347 | |
| 348 ## Request `scripts` | |
| 349 | |
| 350 The request `scripts` retrieves active scripts from the VM. An active script is
source code from which there is still live objects in the VM. This request will
always force a full garbage collection in the VM. | |
| 351 | |
| 352 ``` | |
| 353 { "seq" : <number>, | |
| 354 "type" : "request", | |
| 355 "command" : "scripts", | |
| 356 "arguments" : { "types" : <types of scripts to retrieve | |
| 357 set bit 0 for native scripts | |
| 358 set bit 1 for extension scripts | |
| 359 set bit 2 for normal scripts | |
| 360 (default is 4 for normal scripts)> | |
| 361 "ids" : <array of id's of scripts to return. If this
is not specified all scripts are requrned> | |
| 362 "includeSource" : <boolean indicating whether the source code
should be included for the scripts returned> | |
| 363 "filter" : <string or number: filter string or script i
d. | |
| 364 If a number is specified, then only the scr
ipt with the same number as its script id will be retrieved. | |
| 365 If a string is specified, then only scripts
whose names contain the filter string will be retrieved.> | |
| 366 } | |
| 367 } | |
| 368 ``` | |
| 369 | |
| 370 The request contains an array of the scripts in the VM. This information include
s the relative location of the script within the containing resource. | |
| 371 | |
| 372 ``` | |
| 373 { "seq" : <number>, | |
| 374 "type" : "response", | |
| 375 "request_seq" : <number>, | |
| 376 "command" : "scripts", | |
| 377 "body" : [ { "name" : <name of the script>, | |
| 378 "id" : <id of the script> | |
| 379 "lineOffset" : <line offset within the containing re
source> | |
| 380 "columnOffset" : <column offset within the containing
resource> | |
| 381 "lineCount" : <number of lines in the script> | |
| 382 "data" : <optional data object added through t
he API> | |
| 383 "source" : <source of the script if includeSourc
e was specified in the request> | |
| 384 "sourceStart" : <first 80 characters of the script if
includeSource was not specified in the request> | |
| 385 "sourceLength" : <total length of the script in charac
ters> | |
| 386 "scriptType" : <script type (see request for values)
> | |
| 387 "compilationType" : < How was this script compiled: | |
| 388 0 if script was compiled through
the API | |
| 389 1 if script was compiled through
eval | |
| 390 > | |
| 391 "evalFromScript" : <if "compilationType" is 1 this is th
e script from where eval was called> | |
| 392 "evalFromLocation" : { line : < if "compilationType" is
1 this is the line in the script from where eval was called> | |
| 393 column : < if "compilationType" is
1 this is the column in the script from where eval was called> | |
| 394 ] | |
| 395 "running" : <is the VM running after sending this response> | |
| 396 "success" : true | |
| 397 } | |
| 398 ``` | |
| 399 | |
| 400 Here are a couple of examples. | |
| 401 | |
| 402 ``` | |
| 403 {"seq":117,"type":"request","command":"scripts"} | |
| 404 {"seq":118,"type":"request","command":"scripts","arguments":{"types":7}} | |
| 405 ``` | |
| 406 | |
| 407 ## Request `source` | |
| 408 | |
| 409 The request `source` retrieves source code for a frame. It returns a number of s
ource lines running from the `fromLine` to but not including the `toLine`, that
is the interval is open on the "to" end. For example, requesting source from lin
e 2 to 4 returns two lines (2 and 3). Also note that the line numbers are 0 base
d: the first line is line 0. | |
| 410 | |
| 411 ``` | |
| 412 { "seq" : <number>, | |
| 413 "type" : "request", | |
| 414 "command" : "source", | |
| 415 "arguments" : { "frame" : <frame number (default selected frame)> | |
| 416 "fromLine" : <from line within the source default is line 0> | |
| 417 "toLine" : <to line within the source this line is not inclu
ded in | |
| 418 the result default is the number of lines in the
script> | |
| 419 } | |
| 420 } | |
| 421 ``` | |
| 422 | |
| 423 Response: | |
| 424 | |
| 425 ``` | |
| 426 { "seq" : <number>, | |
| 427 "type" : "response", | |
| 428 "request_seq" : <number>, | |
| 429 "command" : "source", | |
| 430 "body" : { "source" : <the source code> | |
| 431 "fromLine" : <actual from line within the script> | |
| 432 "toLine" : <actual to line within the script this line
is not included in the source> | |
| 433 "fromPosition" : <actual start position within the script> | |
| 434 "toPosition" : <actual end position within the script> | |
| 435 "totalLines" : <total lines in the script> | |
| 436 } | |
| 437 "running" : <is the VM running after sending this response> | |
| 438 "success" : true | |
| 439 } | |
| 440 ``` | |
| 441 | |
| 442 Here are a couple of examples. | |
| 443 | |
| 444 ``` | |
| 445 {"seq":117,"type":"request","command":"source","arguments":{"fromLine":10,"toLin
e":20}} | |
| 446 {"seq":118,"type":"request","command":"source","arguments":{"frame":2,"fromLine"
:10,"toLine":20}} | |
| 447 ``` | |
| 448 | |
| 449 ## Request `setbreakpoint` | |
| 450 | |
| 451 The request `setbreakpoint` creates a new break point. This request can be used
to set both function and script break points. A function break point sets a brea
k point in an existing function whereas a script break point sets a break point
in a named script. A script break point can be set even if the named script is n
ot found. | |
| 452 | |
| 453 ``` | |
| 454 { "seq" : <number>, | |
| 455 "type" : "request", | |
| 456 "command" : "setbreakpoint", | |
| 457 "arguments" : { "type" : <"function" or "script" or "scriptId" or "scri
ptRegExp"> | |
| 458 "target" : <function expression or script identification> | |
| 459 "line" : <line in script or function> | |
| 460 "column" : <character position within the line> | |
| 461 "enabled" : <initial enabled state. True or false, default
is true> | |
| 462 "condition" : <string with break point condition> | |
| 463 "ignoreCount" : <number specifying the number of break point h
its to ignore, default value is 0> | |
| 464 } | |
| 465 } | |
| 466 ``` | |
| 467 | |
| 468 The result of the `setbreakpoint` request is a response with the number of the n
ewly created break point. This break point number is used in the `changebreakpoi
nt` and `clearbreakpoint` requests. | |
| 469 | |
| 470 ``` | |
| 471 { "seq" : <number>, | |
| 472 "type" : "response", | |
| 473 "request_seq" : <number>, | |
| 474 "command" : "setbreakpoint", | |
| 475 "body" : { "type" : <"function" or "script"> | |
| 476 "breakpoint" : <break point number of the new break point> | |
| 477 } | |
| 478 "running" : <is the VM running after sending this response> | |
| 479 "success" : true | |
| 480 } | |
| 481 ``` | |
| 482 | |
| 483 Here are a couple of examples. | |
| 484 | |
| 485 ``` | |
| 486 {"seq":117,"type":"request","command":"setbreakpoint","arguments":{"type":"funct
ion,"target":"f"}} | |
| 487 {"seq":118,"type":"request","command":"setbreakpoint","arguments":{type:"script"
,"target":"test.js","line":100}} | |
| 488 {"seq":119,"type":"request","command":"setbreakpoint","arguments":{"type":"funct
ion,"target":"f","condition":"i > 7"}} | |
| 489 ``` | |
| 490 | |
| 491 | |
| 492 ## Request `changebreakpoint` | |
| 493 | |
| 494 The request `changebreakpoint` changes the status of a break point. | |
| 495 | |
| 496 ``` | |
| 497 { "seq" : <number>, | |
| 498 "type" : "request", | |
| 499 "command" : "changebreakpoint", | |
| 500 "arguments" : { "breakpoint" : <number of the break point to clear> | |
| 501 "enabled" : <initial enabled state. True or false, default
is true> | |
| 502 "condition" : <string with break point condition> | |
| 503 "ignoreCount" : <number specifying the number of break point h
its } | |
| 504 } | |
| 505 ``` | |
| 506 | |
| 507 ## Request `clearbreakpoint` | |
| 508 | |
| 509 The request `clearbreakpoint` clears a break point. | |
| 510 | |
| 511 ``` | |
| 512 { "seq" : <number>, | |
| 513 "type" : "request", | |
| 514 "command" : "clearbreakpoint", | |
| 515 "arguments" : { "breakpoint" : <number of the break point to clear> | |
| 516 } | |
| 517 } | |
| 518 ``` | |
| 519 | |
| 520 Response: | |
| 521 | |
| 522 ``` | |
| 523 { "seq" : <number>, | |
| 524 "type" : "response", | |
| 525 "request_seq" : <number>, | |
| 526 "command" : "clearbreakpoint", | |
| 527 "body" : { "type" : <"function" or "script"> | |
| 528 "breakpoint" : <number of the break point cleared> | |
| 529 } | |
| 530 "running" : <is the VM running after sending this response> | |
| 531 "success" : true | |
| 532 } | |
| 533 ``` | |
| 534 | |
| 535 Here are a couple of examples. | |
| 536 | |
| 537 ``` | |
| 538 {"seq":117,"type":"request","command":"clearbreakpoint","arguments":{"type":"fun
ction,"breakpoint":1}} | |
| 539 {"seq":118,"type":"request","command":"clearbreakpoint","arguments":{"type":"scr
ipt","breakpoint":2}} | |
| 540 ``` | |
| 541 | |
| 542 ## Request `setexceptionbreak` | |
| 543 | |
| 544 The request `setexceptionbreak` is a request to enable/disable breaks on all / u
ncaught exceptions. If the "enabled" argument is not specify, the debuggee will
toggle the state of the specified break type. | |
| 545 | |
| 546 ``` | |
| 547 { "seq" : <number>, | |
| 548 "type" : "request", | |
| 549 "command" : "setexceptionbreak", | |
| 550 "arguments" : { "type" : <string: "all", or "uncaught">, | |
| 551 "enabled" : <optional bool: enables the break type if true> | |
| 552 } | |
| 553 } | |
| 554 ``` | |
| 555 | |
| 556 In response, the break on exception property of the debuggee will be set accordi
ngly, and the following response message will be dispatched to the debugger. | |
| 557 | |
| 558 ``` | |
| 559 { "seq" : <number>, | |
| 560 "type" : "response", | |
| 561 "request_seq" : <number>, | |
| 562 "command" : "setexceptionbreak", | |
| 563 “body” : { "type" : <string: "all" or "uncaught" corresponding to th
e request.>, | |
| 564 "enabled" : <bool: true if the break type is currently enabl
ed as a result of the request> | |
| 565 } | |
| 566 "running" : true | |
| 567 "success" : true | |
| 568 } | |
| 569 ``` | |
| 570 | |
| 571 Here are a few examples. | |
| 572 | |
| 573 ``` | |
| 574 {"seq":117,"type":"request","command":"setexceptionbreak","arguments":{"type":"a
ll"}} | |
| 575 {"seq":118,"type":"request","command":" setexceptionbreak","arguments":{"type":"
all",”enabled”:false}} | |
| 576 {"seq":119,"type":"request","command":" setexceptionbreak","arguments":{"type":"
uncaught","enabled":true}} | |
| 577 ``` | |
| 578 | |
| 579 ## Request `v8flags` | |
| 580 The request v8flags is a request to apply the specified v8 flags (analogous to h
ow they are specified on the command line). | |
| 581 | |
| 582 ``` | |
| 583 { "seq" : <number>, | |
| 584 "type" : "request", | |
| 585 "command" : "v8flags", | |
| 586 "arguments" : { "flags" : <string: a sequence of v8 flags just like those used
on the command line> | |
| 587 } | |
| 588 } | |
| 589 ``` | |
| 590 | |
| 591 In response, the specified flags will be applied in the debuggee if they are leg
al flags. Their effects vary depending on the implementation of the flag. | |
| 592 | |
| 593 ``` | |
| 594 { "seq" : <number>, | |
| 595 "type" : "response", | |
| 596 "request_seq" : <number>, | |
| 597 "command" : "v8flags", | |
| 598 "running" : true | |
| 599 "success" : true | |
| 600 } | |
| 601 ``` | |
| 602 | |
| 603 Here are a few examples. | |
| 604 | |
| 605 ``` | |
| 606 {"seq":117,"type":"request","command":"v8flags","arguments":{"flags":"--trace_gc
—always_compact"}} | |
| 607 {"seq":118,"type":"request","command":" v8flags","arguments":{"flags":"--notrace
_gc"}} | |
| 608 ``` | |
| 609 | |
| 610 ## Request `version` | |
| 611 | |
| 612 The request `version` reports version of the running V8. | |
| 613 | |
| 614 ``` | |
| 615 { "seq" : <number>, | |
| 616 "type" : "request", | |
| 617 "command" : "version", | |
| 618 } | |
| 619 ``` | |
| 620 | |
| 621 Response: | |
| 622 | |
| 623 ``` | |
| 624 { "seq" : <number>, | |
| 625 "type" : "response", | |
| 626 "request_seq" : <number>, | |
| 627 "type" : "request", | |
| 628 "body" : { "V8Version": <string, version of V8> | |
| 629 } | |
| 630 "running" : <is the VM running after sending this response> | |
| 631 "success" : true | |
| 632 } | |
| 633 ``` | |
| 634 | |
| 635 Here is an example. | |
| 636 | |
| 637 ``` | |
| 638 {"seq":1,"type":"request","command":"version"} | |
| 639 {"seq":134,"request_seq":1,"type":"response","command":"version","success":true,
"body":{"V8Version":"1.3.19 (candidate)"},"refs":[],"running":false} | |
| 640 ``` | |
| 641 | |
| 642 ## Request `disconnect` | |
| 643 | |
| 644 The request `disconnect` is used to detach the remote debugger from the debuggee
. This will trigger the debuggee to disable all active breakpoints and resumes
execution if the debuggee was previously stopped at a break. | |
| 645 | |
| 646 ``` | |
| 647 { "seq" : <number>, | |
| 648 "type" : "request", | |
| 649 "command" : "disconnect", | |
| 650 } | |
| 651 ``` | |
| 652 | |
| 653 The only response for the `disconnect` request is the response to a connect requ
est if the debugger is still able to get a response before the debuggee successf
ully disconnects. | |
| 654 | |
| 655 Here is an examples: | |
| 656 | |
| 657 ``` | |
| 658 {"seq":117,"type":"request","command":"disconnect"} | |
| 659 ``` | |
| 660 | |
| 661 ## Request `gc` | |
| 662 The request `gc` is a request to run the garbage collector in the debuggee. | |
| 663 | |
| 664 ``` | |
| 665 { "seq" : <number>, | |
| 666 "type" : "request", | |
| 667 "command" : "gc", | |
| 668 "arguments" : { "type" : <string: "all">, | |
| 669 } | |
| 670 } | |
| 671 ``` | |
| 672 | |
| 673 In response, the debuggee will run the specified GC type and send the following
response message: | |
| 674 | |
| 675 ``` | |
| 676 { "seq" : <number>, | |
| 677 "type" : "response", | |
| 678 "request_seq" : <number>, | |
| 679 "command" : "gc", | |
| 680 “body” : { "before" : <int: total heap usage in bytes before the GC>, | |
| 681 "after" : <int: total heap usage in bytes after the GC> | |
| 682 } | |
| 683 "running" : true | |
| 684 "success" : true | |
| 685 } | |
| 686 ``` | |
| 687 | |
| 688 Here is an example. | |
| 689 | |
| 690 ``` | |
| 691 {"seq":117,"type":"request","command":"gc","arguments":{"type":"all"}} | |
| 692 ``` | |
| 693 | |
| 694 ## Request `listbreakpoints` | |
| 695 | |
| 696 The request `listbreakpoints` is used to get information on breakpoints that may
have been set by the debugger. | |
| 697 | |
| 698 ``` | |
| 699 { "seq" : <number>, | |
| 700 "type" : "request", | |
| 701 "command" : "listbreakpoints", | |
| 702 } | |
| 703 ``` | |
| 704 | |
| 705 Response: | |
| 706 | |
| 707 ``` | |
| 708 { "seq" : <number>, | |
| 709 "type" : "response", | |
| 710 "request_seq" : <number>, | |
| 711 "command" : "listbreakpoints", | |
| 712 "body" : { "breakpoints": [ { "type" : <string: "scriptId"
or "scriptName".>, | |
| 713 "script_id" : <int: script id. On
ly defined if type is scriptId.>, | |
| 714 "script_name" : <string: script name
. Only defined if type is scriptName.>, | |
| 715 "number" : <int: breakpoint num
ber. Starts from 1.>, | |
| 716 "line" : <int: line number of
this breakpoint. Starts from 0.>, | |
| 717 "column" : <int: column number
of this breakpoint. Starts from 0.>, | |
| 718 "groupId" : <int: group id of th
is breakpoint.>, | |
| 719 "hit_count" : <int: number of time
s this breakpoint has been hit. Starts from 0.>, | |
| 720 "active" : <bool: true if this
breakpoint is enabled.>, | |
| 721 "ignoreCount" : <int: remaining numb
er of times to ignore breakpoint. Starts from 0.>, | |
| 722 "actual_locations" : <actual locations of
the breakpoint.>, | |
| 723 } | |
| 724 ], | |
| 725 "breakOnExceptions" : <true if break on all exceptio
ns is enabled>, | |
| 726 "breakOnUncaughtExceptions" : <true if break on uncaught exc
eptions is enabled> | |
| 727 } | |
| 728 "running" : <is the VM running after sending this response> | |
| 729 "success" : true | |
| 730 } | |
| 731 ``` | |
| 732 | |
| 733 Here is an examples: | |
| 734 | |
| 735 ``` | |
| 736 {"seq":117,"type":"request","command":"listbreakpoints"} | |
| 737 ``` | |
| 738 | |
| 739 | |
| 740 ## Request `setvariablevalue` | |
| 741 This requests sets the value of a variable from the specified scope. | |
| 742 | |
| 743 Request: | |
| 744 | |
| 745 ``` | |
| 746 { "seq" : <number>, | |
| 747 "type" : "request", | |
| 748 "command" : "setvariablevalue", | |
| 749 "arguments : { "name" : <string: variable name>, | |
| 750 "scope" : { "number" : <scope number> | |
| 751 "frameNumber" : <frame number, optional uses selec
ted frame if missing> | |
| 752 } | |
| 753 } | |
| 754 } | |
| 755 ``` | |
| 756 | |
| 757 Response: | |
| 758 | |
| 759 ``` | |
| 760 { "seq" : <number>, | |
| 761 "type" : "response", | |
| 762 "request_seq" : <number>, | |
| 763 "type" : "request", | |
| 764 "body" : { "newValue": <object: mirror object of the new value> } | |
| 765 "running" : <is the VM running after sending this response> | |
| 766 "success" : true | |
| 767 } | |
| 768 ``` | |
| 769 | |
| 770 # Events | |
| 771 | |
| 772 ## Event `break` | |
| 773 | |
| 774 The event `break` indicate that the execution in the VM has stopped due to a bre
ak condition. This can be caused by an unconditional break request, by a break p
oint previously set, a stepping action have completed or by executing the `debug
ger` statement in JavaScript. | |
| 775 | |
| 776 ``` | |
| 777 { "seq" : <number>, | |
| 778 "type" : "event", | |
| 779 | |
| 780 "event" : "break", | |
| 781 "body" : { "invocationText" : <text representation of the stack frame>, | |
| 782 "sourceLine" : <source line where execution is stopped>, | |
| 783 "sourceColumn" : <column within the source line where execution
is stopped>, | |
| 784 "sourceLineText" : <text for the source line where execution is st
opped>, | |
| 785 "script" : { name : <resource name of the origin o
f the script> | |
| 786 lineOffset : <line offset within the origin
of the script> | |
| 787 columnOffset : <column offset within the orig
in of the script> | |
| 788 lineCount : <number of lines in the script
> | |
| 789 "breakpoints" : <array of break point numbers hit if any> | |
| 790 } | |
| 791 } | |
| 792 ``` | |
| 793 | |
| 794 Here are a couple of examples. | |
| 795 | |
| 796 ``` | |
| 797 {"seq":117,"type":"event","event":"break","body":{"functionName":"f","sourceLine
":1,"sourceColumn":14}} | |
| 798 {"seq":117,"type":"event","event":"break","body":{"functionName":"g","scriptData
":"test.js","sourceLine":12,"sourceColumn":22,"breakpoints":[1]}} | |
| 799 {"seq":117,"type":"event","event":"break","body":{"functionName":"h","sourceLine
":100,"sourceColumn":12,"breakpoints":[3,5,7]}} | |
| 800 ``` | |
| 801 | |
| 802 ## Event `exception` | |
| 803 | |
| 804 The event `exception` indicate that the execution in the VM has stopped due to a
n exception. | |
| 805 | |
| 806 ``` | |
| 807 { "seq" : <number>, | |
| 808 "type" : "event", | |
| 809 "event" : "exception", | |
| 810 "body" : { "uncaught" : <boolean>, | |
| 811 "exception" : ... | |
| 812 "sourceLine" : <source line where the exception was thrown>, | |
| 813 "sourceColumn" : <column within the source line from where the e
xception was thrown>, | |
| 814 "sourceLineText" : <text for the source line from where the except
ion was thrown>, | |
| 815 "script" : { "name" : <name of script> | |
| 816 "lineOffset" : <number> | |
| 817 "columnOffset" : <number> | |
| 818 "lineCount" : <number> | |
| 819 } | |
| 820 | |
| 821 } | |
| 822 } | |
| 823 ``` | |
| 824 | |
| 825 # Response object serialization | |
| 826 | |
| 827 Some responses contain objects as part of the body, e.g. the response to the eva
luate request contains the result of the expression evaluated. | |
| 828 | |
| 829 All objects exposed through the debugger is assigned an ID called a handle. This
handle is serialized and can be used to identify objects. A handle has a certai
n lifetime after which it will no longer refer to the same object. Currently the
lifetime of handles match the processing of a debug event. For each debug event
handles are recycled. | |
| 830 | |
| 831 An object can be serialized either as a reference to a given handle or as a valu
e representation containing the object content. | |
| 832 | |
| 833 An object serialized as a reference looks follows this where `<handle>` is an in
teger. | |
| 834 | |
| 835 ``` | |
| 836 {"ref":<handle>} | |
| 837 ``` | |
| 838 | |
| 839 For objects serialized as value they all contains the handle and the type of the
object. | |
| 840 | |
| 841 ``` | |
| 842 { "handle" : <handle>, | |
| 843 "type" : <"undefined", "null", "boolean", "number", "string", "object", "fun
ction" or "frame"> | |
| 844 } | |
| 845 ``` | |
| 846 | |
| 847 In some situations special transient objects are created by the debugger. These
objects are not really visible in from JavaScript, but are created to materializ
e something inside the VM as an object visible to the debugger. One example of t
his is the local scope object returned from the `scope` and `scopes` request. Tr
ansient objects are identified by having a negative handle. A transient object c
an never be retrieved using the `lookup` request, so all transient objects refer
enced will be in the `refs` part of the response. The lifetime of transient obje
cts is basically the request they are involved in. | |
| 848 | |
| 849 For the primitive JavaScript types `undefined` and `null` the type describes the
value fully. | |
| 850 | |
| 851 ``` | |
| 852 {"handle":<handle>,"type":"undefined"} | |
| 853 ``` | |
| 854 | |
| 855 ``` | |
| 856 {"handle":<handle>,"type":"null"} | |
| 857 ``` | |
| 858 | |
| 859 For the rest of the primitive types `boolean`, `number` and `string` the value i
s part of the result. | |
| 860 | |
| 861 ``` | |
| 862 { "handle":<handle>, | |
| 863 "type" : <"boolean", "number" or "string"> | |
| 864 "value" : <JSON encoded value> | |
| 865 } | |
| 866 ``` | |
| 867 | |
| 868 Boolean value. | |
| 869 | |
| 870 ``` | |
| 871 {"handle":7,"type":"boolean","value":true} | |
| 872 ``` | |
| 873 | |
| 874 Number value. | |
| 875 | |
| 876 ``` | |
| 877 {"handle":8,"type":"number","value":42} | |
| 878 ``` | |
| 879 | |
| 880 String value. | |
| 881 | |
| 882 ``` | |
| 883 {"handle":9,"type":"string","value":"a string"} | |
| 884 ``` | |
| 885 | |
| 886 An object is encoded with additional information. | |
| 887 | |
| 888 ``` | |
| 889 { "handle" : <handle>, | |
| 890 "type" : "object", | |
| 891 "className" : <Class name, ECMA-262 property [[Class]]>, | |
| 892 "constructorFunction" : {"ref":<handle>}, | |
| 893 "protoObject" : {"ref":<handle>}, | |
| 894 "prototypeObject" : {"ref":<handle>}, | |
| 895 "properties" : [ {"name" : <name>, | |
| 896 "ref" : <handle> | |
| 897 }, | |
| 898 ... | |
| 899 ] | |
| 900 } | |
| 901 ``` | |
| 902 | |
| 903 The difference between the `protoObject` and the `prototypeObject` is that the `
protoObject` contains a reference to the actual prototype object (for which acce
ssibility is not defined in ECMA-262, but in V8 it is accessible using the `__pr
oto__` property) whereas the `prototypeObject` is the value of the `prototype` p
roperty. | |
| 904 | |
| 905 Here is an example. | |
| 906 | |
| 907 ``` | |
| 908 {"handle":3,"type":"object","className":"Object","constructorFunction":{"ref":4}
,"protoObject":{"ref":5},"prototypeObject":{"ref":6},"properties":[{"name":"a","
ref:7},{"name":"b","ref":8}]} | |
| 909 ``` | |
| 910 | |
| 911 An function is encoded as an object but with additional information in the prope
rties `name`, `inferredName`, `source` and `script`. | |
| 912 | |
| 913 ``` | |
| 914 { "handle" : <handle>, | |
| 915 "type" : "function", | |
| 916 "className" : "Function", | |
| 917 "constructorFunction" : {"ref":<handle>}, | |
| 918 "protoObject" : {"ref":<handle>}, | |
| 919 "prototypeObject" : {"ref":<handle>}, | |
| 920 "name" : <function name>, | |
| 921 "inferredName" : <inferred function name for anonymous functions> | |
| 922 "source" : <function source>, | |
| 923 "script" : <reference to function script>, | |
| 924 "scriptId" : <id of function script>, | |
| 925 "position" : <function begin position in script>, | |
| 926 "line" : <function begin source line in script>, | |
| 927 "column" : <function begin source column in script>, | |
| 928 "properties" : [ {"name" : <name>, | |
| 929 "ref" : <handle> | |
| 930 }, | |
| 931 ... | |
| 932 ] | |
| 933 } | |
| 934 ``` | |
| OLD | NEW |
|---|
Chromium Code Reviews
Issue 1459823002:
[Docs] Removed unused docs because they are moved to GitHub (Closed)
Base URL: https://chromium.googlesource.com/v8/v8.git@master