| 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 1347153006:
[Docs] Add wiki content to Markdown docs (Closed)
Base URL: https://chromium.googlesource.com/v8/v8.git@master