{"id":19413939,"url":"https://github.com/swojtasiak/jsrdbg","last_synced_at":"2026-03-04T16:02:56.087Z","repository":{"id":30236640,"uuid":"33787800","full_name":"swojtasiak/jsrdbg","owner":"swojtasiak","description":"JavaScript Remote Debugger for SpiderMonkey.","archived":false,"fork":false,"pushed_at":"2019-06-23T11:54:20.000Z","size":339,"stargazers_count":25,"open_issues_count":1,"forks_count":8,"subscribers_count":4,"default_branch":"master","last_synced_at":"2025-04-03T04:33:21.772Z","etag":null,"topics":["debugger","debugger-engine","javascript","shared-library","spidermonkey-engine"],"latest_commit_sha":null,"homepage":"","language":"C++","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"lgpl-2.1","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/swojtasiak.png","metadata":{"files":{"readme":"README","changelog":"ChangeLog","contributing":null,"funding":null,"license":"COPYING","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null}},"created_at":"2015-04-11T18:45:17.000Z","updated_at":"2024-07-06T20:20:00.000Z","dependencies_parsed_at":"2022-08-30T03:21:59.845Z","dependency_job_id":null,"html_url":"https://github.com/swojtasiak/jsrdbg","commit_stats":null,"previous_names":[],"tags_count":8,"template":false,"template_full_name":null,"purl":"pkg:github/swojtasiak/jsrdbg","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/swojtasiak%2Fjsrdbg","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/swojtasiak%2Fjsrdbg/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/swojtasiak%2Fjsrdbg/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/swojtasiak%2Fjsrdbg/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/swojtasiak","download_url":"https://codeload.github.com/swojtasiak/jsrdbg/tar.gz/refs/heads/master","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/swojtasiak%2Fjsrdbg/sbom","scorecard":null,"host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":286080680,"owners_count":30085828,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2026-03-04T15:40:14.053Z","status":"ssl_error","status_checked_at":"2026-03-04T15:40:13.655Z","response_time":59,"last_error":"SSL_read: unexpected eof while reading","robots_txt_status":"success","robots_txt_updated_at":"2025-07-24T06:49:26.215Z","robots_txt_url":"https://github.com/robots.txt","online":false,"can_crawl_api":true,"host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["debugger","debugger-engine","javascript","shared-library","spidermonkey-engine"],"created_at":"2024-11-10T12:35:35.390Z","updated_at":"2026-03-04T16:02:55.995Z","avatar_url":"https://github.com/swojtasiak.png","language":"C++","funding_links":[],"categories":[],"sub_categories":[],"readme":"JavaScript Remote Debugger\n==========================\n\nThe following chapters describe some of the most important features of\nthe project.\n\nWhat it is for?\n---------------\n\nThis is an implementation of a high level debugging protocol for\nSpiderMonkey engine which is available as a shared library. The library\ncan be used to integrate debugging facilities into an existing\napplication leveraging SpiderMonkey engine. There are several\nintegration possibilities including exposition of the high level\ndebugger API locally directly to the application and even exposing it to\nremote clients using full duplex TCP/IP communication.\n\nThe project consists of two main parts. The debugger engine itself in a\nform of shared library and the standalone console client application\nused to connect to the debugger remotely. It's a simple console based\nimplementation whose idea is similar to GNU debugger.\n\nArchitecture, integration and remote client are described in the\nfollowing chapters.\n\nInstall\n-------\n\n### Linux\n\n#### Dependencies\n\nBesides a working C++ compiler you need a few additional dependencies to\ncompile jsrdbg.\n\nOn Fedora:\n\n~~~~ {.sh}\nsudo dnf install \\\n    autoconf \\\n    autoconf-archive \\\n    automake \\\n    gettext-devel \\\n    libtool \\\n    mozjs24-devel \\\n    readline-devel\n~~~~\n\nOn Ubuntu:\n\n~~~~ {.sh}\nsudo apt-get install \\\n    autoconf \\\n    autoconf-archive \\\n    build-essential \\\n    gettext \\\n    libmozjs-24-dev \\\n    libreadline-dev \\\n    libtool \\\n    pkg-config\n~~~~\n\nNote: If you haven't installed mozjs-24 with your distribution's package\nmanager you probably have to tell pkg-config where to find the\n`mozjs-24.pc` file. You can do this by setting the `PKG_CONFIG_PATH`\nenvironment variable appropriately, e.g.\n\n~~~~ {.sh}\n$ PKG_CONFIG_PATH=/usr/local/lib/pkgconfig\n~~~~\n\nOn Linux, you can build jsrdbg with the usual\n`./configure \u0026\u0026 make \u0026\u0026 make install` like so\n\n~~~~ {.sh}\n$ autoreconf -i\n$ ./configure\n$ make\n$ sudo make install\n~~~~\n\n### Windows\n\nOn Windows, jsrdbg provides Visual Studio project files in the `win/`\ndirectory to create a Windows DLL. We have tested building jsrdbg with\nVisual Studio 2012 but it should work with any later version as well.\n\nIt is important that you checkout the win-iconv submodule that is\nreferenced by the jsrdbg Git repository when compiling on Windows. You\ncan do this by either cloning the repository as follows\n\n    git clone --recursive https://github.com/swojtasiak/jsrdbg.git\n\nor by checking out the submodule after the fact like this:\n\n    git submodule init\n    git submodule update\n\nAdditionally, you need to set two environment variables to let Visual\nStudio know where to find the SpiderMonkey header files at compile-time\nand the SpiderMonkey import library at link-time. Make sure to set both\nenvironment variables to the appropriate paths before opening Visual\nStudio.\n\n    set MOZJS_INCLUDE_DIR=C:\\mozjs-24\\include\\js\n    set MOZJS_LIB_PATH=C:\\mozjs-24\\lib\\mozjs-24.lib\n\nThen build the solution with Visual Studio Solution as usual.\n\nNote: On Windows, jsrdbg logs to a file by default. (On Linux, jsrdbg\nlogs via the syslog(3) facility, which is of course unavailable on\nWindows.) You can specify the log file by setting the\n`JSRDBG_LOG_FILE_PATH` environment variable before starting your\nprogram, e.g.\n\n    set JSRDBG_LOG_FILE_PATH=C:\\Users\\test\\Desktop\\jsrdbg.log\n\nIf the environment variable is not set, jsrdbg does not write any logs.\n\nHow to integrate\n----------------\n\nThere are plenty of ways how an application can be integrated with a\ndebugger, but the easier one is probably to integrate it with a remote\ndebugger which is based on TCP/IP connections. It's probably the best\nchoice, due to the fact that integration is really simple and the\ndebugger is fully functional without any additional work, which is\nneeded in case of the local debugger implementation. In order to\nintegrate with the local debugger you have to inherit from an abstract\ndebugger implementation and provide some methods that are exposed by the\nclass.\n\nAs has been said, the integration process is really simple and can be\ncompleted in a few lines of code. The working example is available in\nthe \"example\" directory in the project root directory. The example\nitself is really simple, the character encoding is broken and there is\nalmost no error handling, but it shows how the process of integration\nlooks like.\n\nHaving working SpiderMonkey engine embedded in your code, everything you\nhave to do is to create a new instance of the JSRemoteDebugger class\nwhich needs JSRemoteDebuggerCfg instance when initialized. Notice that\nthe debugger itself is not connected to any specific JSRuntime and\nJSContext instance. It's designed to make integration of various\nJSContexts as simple as possible. Everything you have to care about is\nto make sure that you call debuggers methods using the same threads that\nare to run JS runtimes. So it's entirely possible to use only one\ndebugger instance bounded to one specific TCP/IP port to handle all\nJSContexts within a process.\n\nInitializing a remote debugger instance you can provide dedicated\nconfiguration for the remote debugger itself as well as directly for a\ndebugger engine. That is, two of the available implementations (local\nand remote) use the same high level debugger engine under the hood, so\nthey share the same set of configuration options.\n\nSo being familiar with that, we can try to prepare fully configured\nremote debugger instance for our own application. Let's say we need to\nbind it only to the localhost and to the default TCP/IP port 8089. We\nalso would like the debugger to suspend as soon as a debuggee started in\norder to debug the script from the beginning. Nothing easier than that:\n\n~~~~ {.cpp}\nJSRemoteDebuggerCfg cfg;\ncfg.setTcpHost(\"localhost\");\ncfg.setTcpPort(JSR_DEFAULT_TCP_PORT);\ncfg.setScriptLoader(\u0026loader);\n\nJSRemoteDebugger dbg( cfg );\n~~~~\n\nIn the first line the new configuration object is created. It's the\nmentioned dedicated configuration for the remote debugger\nimplementation. In the second and third line two configuration options\nare set. The first one is the host we would like to listen on and the\nnext one is the TCP/IP port. That's basically all we have to do here.\nThere is one more important option around: 'scriptLoader', which can be\nused to provide scripts source code for the debugging engine, but let's\nleave it for now. The last one can be used to choose between available\nprotocols supported by the debugger, but currently only TCP/IP is\nsupported which is a default protocol, so for now this option is\nuseless.\n\nIn the last line an instance of remote debugger is being created for our\nconfiguration options prepared earlier.\n\nHaving the debugger created you have to install it. In order to\nunderstand the installation process you have to be aware of one\nimportant fact. The core of the debugger engine is implemented in\nJavaScript language and it runs in the same virtual machine which is\ndebugged by the debugger engine. Of course there is plenty of C++ code\nwhich handles whole communication etc., but the debugger itself is a\npure JavaScript code which uses some provided native interfaces to\nexchange communicates with the C++ part. Therefore the installation\nprocedure of the debugger engine is neither more nor less about creating\ndedicated compartment inside existing SpiderMonkey engine and running a\nbootstrapping code which registers the debugger. In order to do it you\nhave to call a dedicated method: 'install' exposed by debugger instance.\nThe method gets three arguments: JSContext which we would like to debug.\nA name of the context which is just a kind of identifier used on the\nclient level just in order to communicate with concrete context\ninstance. The last one holds debugger engine configuration parameters\nJSDbgEngineOptions.\n\nWhen the installation is completed you have your debugger engine up and\nrunning, but we need a way to do some interaction with it. Protocol\nmentioned before is responsible for exposing communication interface. In\nour case it's TCP/IP protocol, so the next thing we have to do is to\nstart the TCP/IP server handling the communication logic. Of course this\nlogic is also hidden under a layer of abstraction, therefore everything\nthat has to be done is to call another parameter-free method: 'start' on\ndebugger instance. Remember that the protocol exposed by the debugger is\nfully asynchronous one and the whole communication is handled by a full\nduplex TCP/IP server. It's why there is a new thread started in the\nbackground after calling 'start' method.\n\nOK, that's pretty much everything you have to do in order to connect to\nthe debugger remotely. So let's look at the source code:\n\n~~~~ {.cpp}\nJSDbgEngineOptions dbgOptions;\ndbgOptions.suspended();\n\nif( dbg.install( cx, 'example-js-context', dbgOptions ) != JSR_ERROR_NO_ERROR ) {\n    cout \u003c\u003c \"Cannot install debugger.\" \u003c\u003c endl;\n    return false;\n}\n\nif( dbg.start() != JSR_ERROR_NO_ERROR ) {\n    dbg.uninstall();\n    cout \u003c\u003c \"Cannot start debugger.\" \u003c\u003c endl;\n    return false;\n}\n~~~~\n\nThe lines first and second are responsible for providing options for the\ndebugger engine. Currently only three options are available. The first\none called 'suspended' can be used to start debugger in the suspended\nmode mentioned before, 'continueWhenNoConnections' which should be set\nif we would like to make the debugging application continue when all\nremote client have disconnected and the last one 'sourceDisplacement'\nused to synchronize source code position if JS engine being debugged\nmesses up with line numbers.\n\nThe rest of the code explains itself. Only one thing that might be\nreally interesting here is the model of error handling. Every method\nexposed by the debugging engine returns one of the unified error codes.\nAll the codes are available in the following header file:\njsrdbg/jsdbg\\_common.h. Bear in mind that it's up to you to uninstall\nevery context correctly before deleting the debugger. Debugger cannot do\nit automatically just because every 'uninstall' invocation has to be\ndone on dedicated thread, the same which runs the JS engine being\nunregistered.\n\nDebugger is up and running now, but you have to add every compartment\nyou would like to debug into the debugger, by providing its JS global\nobject. It can be done using 'addDebuggee' method like as in the\nfollowing code:\n\n~~~~ {.cpp}\nif( dbg.addDebuggee( cx, global ) != JSR_ERROR_NO_ERROR ) {\n    dbg.uninstall( cx );\n    cout \u003c\u003c \"Cannot add debuggee.\" \u003c\u003c endl;\n    return false;\n}\n~~~~\n\nThat's all. If you have done all the steps correctly there is much a\nchance that everything works and you should be able to use jrdb client\nin order to make a remote connection to the debugger.\n\nOf curse it's a very young project, so there is always a risk of a nasty\nbug or something, so do not hesitate to report everything or provide a\npatch if you find something.\n\nAs was said before, there is also a local debugger available, but its\nintegration is quite complex. There is 'check' subproject which is used\nto run all unit tests. Take a look at it in order to get a real example\nof its usage.\n\nRemote client\n-------------\n\nInside 'jrdb' directory, there is a simple remote debugger client\navailable. It was designed and implemented having gdb in mind, so it's\nquite similar to the gdb, but only a small subset of all gdb commands is\nimplemented for now.\n\nAnyway the client is not the most convenient one as it doesn't use\nncurses, but it's definitely better than nothing :-). I will probably\nprepare a client with a real GUI in the future, but I don't have time\nfor it now.\n\nOk, so let's start with a simple example.\n\nFirst of all go to the example directory and build the provided example.\nIt's a very simple application which runs an embedded JS script and\nexposing remote debugger instance. The application binds to all\ninterfaces and uses the default TCP/IP port 8089. In order to build\neverything go to the example directory and run:\n\n~~~~ {.sh}\n$ autoreconf -i\n$ ./configure\n$ make\n~~~~\n\nBear in mind that the project uses pkg-config to find libjsrdbg shared\nlibrary. So you have to install jsrdbg and make sure that\n`PKG_CONFIG_PATH` is set correctly. For instance, if you are installing\nthe project in /usr/local, then there is always a risk that you will\nhave to set the following environment variable:\n\n~~~~ {.sh}\n$ export PKG_CONFIG_PATH=/usr/local/lib/pkgconfig\n~~~~\n\nIt depends if your system handles this location by default.\n\nNow after building the example, you have the following application in\nthe \"src\" directory: jsrdbg\\_example.\n\nJust run it.\n\nIt should print the following messages into the standard output:\n\n    $ src/jsrdbg_example\n    Use jrdb command in order to connect to the debugger.\n    Application is suspended.\n\nOK, it means that application has been started in the suspended mode\ndescribed before and is waiting for new connections. It uses the default\nTCP/IP port, so everything that has to be done to connect it is to run\njrdb.\n\nFirst of all type --help parameter in order to get all available\narguments:\n\n~~~~ {.sh}\n$ jrdb --help\n~~~~\n\nThen start the client:\n\n    $ jrdb\n    JavaScript Remote Debugger Client connected to a remote debugger.\n    Waiting for a list of JavaScript contexts being debugged.\n    Type \"help context\" for more information.\n    Available JSContext instances:\n    0) example-JS (PAUSED)\n    There is only one JSContext managed by the debugger, so it has been chosen as\n    the current one. You can change it using the \"context\" command.\n    jrdb\u003e\n\nAs you can see the client informed us that debugger we are connected to\nprovides one paused JSContext which can be debugged. As there is only\none context, it has been chosen as the current one by default. Type\n'help context' in order to get more comprehensive explanation.\n\nThe jsrd\\\u003e prompt means that the client is waiting for commands. So try\nto type the most important one:\n\n    jrdb\u003e help\n    List of available commands.\n\n    set - Sets environment variables\n    env - Prints environment variables\n    pc - Prints information about current frame\n    step - Steps to a next instruction\n    next - Steps to a next instructions going through subroutines\n    continue - Continues execution of the program being debugged\n    stop - Terminates a debuggee.\n    break,pause - Pauses the program being debugged or sets breakpoints\n    delete - Deletes breakpoints\n    info - List information about program being debugged\n    list - Prints source code of the script being debugged\n    backtrace - Prints backtrace of stack frames\n    print - Evaluates expressions\n    version - Shows application version\n    source - Loads script source code\n    animation - Enables/disables stepping animation\n    jrdb\u003e\n\nAs you can see it's not the most sophisticated one. It just prints some\ninformation about supported commands, so it's definitely one of the most\nhelpful ones :-). In order to get more comprehensive description of\nevery command you can type its name as an argument:\n\n    jrdb\u003e help list\n    Lists number of source code lines starting from the\n    location where debuggee is paused. When run first time\n    it requests for the whole source code of the script being\n    debugged and caches it. It's why first call for a particular\n    script can be a bit slower.\n    Usage:\n    list [n]\n    l [n]\n    [n] - Number of source lines to print.\n    jrdb\u003e\n\nOK, so instead of describing every command available, let's do some\nexercises using the example application started a moment ago. First of\nall type 'pc' and hit enter. You should see something like that:\n\n    jrdb\u003e pc\n    Script: example.js\n    Line: 0\n    jrdb\u003e\n\nIt means that we are paused inside the \"example.js\" script at line 0.\nOk, so it would be definitelly helpful if we have an opportunity to see\na piece of source code at this location. Nothing easier than that:\n\n    jrdb\u003e l\n     0* debugger;\n     1  print('Hello. ');\n     2  (function(fn) {\n     3      print('Yes, ');\n     4      fn('this is dog.');\n     5  })(function(msg) {\n     6      print(msg);\n     7  });\n     8  print('Woof, woof.');\n     9  debugger;\n    jrdb\u003e\n\nThe 'list' command can be used to show a number of source lines just\nafter the point where debugger is currently paused. The asterisk after\nthe line number tells us where we are paused. In this particular case we\nare paused on 'debugger' statement which is quite interesting one,\nbecause it can be used directly in the code as a breakpoint in order to\nmake the debugger pause the application. OK, so let's step through the\nnext few instructions.\n\n    jrdb\u003e s\n    1 print('Hello. ');\n    jrdb\u003e s\n    2 (function(fn) {\n    jrdb\u003e s\n    5 })(function(msg) {\n    jrdb\u003e s\n    2 (function(fn) {\n    jrdb\u003e s\n    3     print('Yes, ');\n    jrdb\u003e l\n     3*     print('Yes, ');\n     4      fn('this is dog.');\n     5  })(function(msg) {\n     6      print(msg);\n     7  });\n     8  print('Woof, woof.');\n     9  debugger;\n    10\n    jrdb\u003e\n\nAs you can see we have gone through a few source code lines using 'step'\ninstruction and after doing it we are paused at the third line. There is\none argument to the function we are in. It's 'fn'. Let's see what it is.\nIt can be done using print function, which is used to evaluate code:\n\n    jrdb\u003e p fn\n    {\n      \"___jsrdbg_function_desc___\": {\n        \"parameterNames\": [\n          \"msg\"\n        ]\n      },\n      \"prototype\": {\n        \"___jsrdbg_collapsed___\": true\n      },\n      \"length\": 1,\n      \"name\": \"\",\n      \"arguments\": null,\n      \"caller\": null\n    }\n    jrdb\u003e\n\nSo it's an anonymous function with one argument 'msg'.\n\nHmm, 'print' evaluates code. So let's try to do something strange:\n\n    jrdb\u003e p fn = function() { debugger; };\n    {\n      \"___jsrdbg_function_desc___\": {\n        \"displayName\": \"fn\",\n        \"parameterNames\": []\n      },\n      \"prototype\": {\n        \"___jsrdbg_collapsed___\": true\n      },\n      \"length\": 0,\n      \"name\": \"\",\n      \"arguments\": null,\n      \"caller\": null\n    }\n    jrdb\u003e c\n    debugger eval code\n    1\n    jrdb\u003e\n\nWhat has just happened? It's a bit tricky but in fact very simple. The\nmentioned print method is used to evaluate the code as it is. So by\nevaluating the following instruction: 'fn = function() { debugger; };'\nwe replaced the original function passed to the method using the 'fn'\nargument by a new one, which does only one thing pauses when executed.\nIt's why the debugger paused in the evaluated code after we continued\nexecution using 'continue' command. So as you can see you have really\npretty much control over the debugged code. But remember that with great\npower comes great responsibility, it's not really hard to break the\nwhole debugged application using such evaluation. OK, let's go out from\nthe evaluated code. Remember that you can display all local variables\nusing 'info locals' command, but head over to the 'help' description,\nbecause it can be a quite tricky instruction and you probably will be\ninterested how to control the depth of displayed variables.\n\nThat's should be enough for now. With such a knowledge you should be\nable to play with the debugger on your own using 'help' command.\n\n    jrdb\u003e s\n    1\n    jrdb\u003e s\n    example.js\n    4     fn('this is dog.');\n    jrdb\u003e\n\nSome interesting commands:\n\n*set debug=true* - Enables debug mode. All sent and received packets\nwill be displayed in the console as well as log messages from the\nclient.\n\n*animation* - If enabled, every time when client receives information\nthat debugger has paused, it displays bigger source context and\nhighlights the line where debugger is paused. For instance:\n\n    jrdb\u003e s\n     0  debugger;\n     1\u003e print('Hello. ');\n     2  (function(fn) {\n     3      print('Yes, ');\n     4      fn('this is dog.');\n     5  })(function(msg) {\n     6      print(msg);\n     7  });\n     8  print('Woof, woof.');\n     9  debugger;\n    10\n    jrdb\u003e s\n     0  debugger;\n     1  print('Hello. ');\n     2\u003e (function(fn) {\n     3      print('Yes, ');\n     4      fn('this is dog.');\n     5  })(function(msg) {\n     6      print(msg);\n     7  });\n     8  print('Woof, woof.');\n     9  debugger;\n    10\n    jrdb\u003e\n\n*source* - Returns list of available script files.\n\n    jrdb\u003e source\n    /home/tas/workspace_gnome/gjs/examples/gtk.js\n    resource:///org/gnome/gjs/modules/overrides/GLib.js\n    resource:///org/gnome/gjs/modules/lang.js\n\nProtocol\n--------\n\nThe whole protocol is based on full duplex TCP/IP communication. Almost\nevery command and response is encoded using JSON. So after implementing\ntransport layer everything you have to do to communicate with a debugger\nis to send and receive JSON encoded objects. For instance the following\npackets show how a few step commands look like on the protocol level:\n\n    Sending command: {\"id\":1,\"type\":\"command\",\"name\":\"step\"}\n    Got packet: {\"type\":\"info\",\"subtype\":\"paused\",\"url\":\"test_script.js\",\"line\":5,\n    \"source\":\"Utils.sum = function(x, y) {\"}\n    Sending command: {\"id\":2,\"type\":\"command\",\"name\":\"step\"}\n    Got packet: {\"type\":\"info\",\"subtype\":\"paused\",\"url\":\"test_script.js\",\"line\":12,\n    \"source\":\"Manager.prototype = {\"}\n    Sending command: {\"id\":3,\"type\":\"command\",\"name\":\"step\"}\n    Got packet: {\"type\":\"info\",\"subtype\":\"paused\",\"url\":\"test_script.js\",\"line\":13,\n    \"source\":\"    calculate: function( x ) {\"}\n    Sending command: {\"id\":4,\"type\":\"command\",\"name\":\"step\"}\n    Got packet: {\"type\":\"info\",\"subtype\":\"paused\",\"url\":\"test_script.js\",\"line\":20,\n    \"source\":\"    show: function(x) {\"}\n\n    \"source\":\"manager.calculate(5);\"}\n\nThis chapter describes all available commands and responses, so after\nreading it you should be able to implement a client application for the\ndebugger.\n\nThere are also two special commands, which are not encoded using JSON.\nThese are: get\\_available\\_contexts and exit.\n\n### Request\n\nRequest is normalized and consists of following parts:\n\n\\*[context id]/(JSON PACKET)\\n*\n\n-   *context id* - Numerical identifier of the JSContext we would like\n    to send packet to. It's optional parameter in case of non-existence\n    the packet is sent to all the contexts.\n-   *JSON PACKET* - Command itself, mandatory.\n-   \\*\\n* - Commands are separated by new-line characters.\n\nJSON packet consists of the following properties:\n\n-   *type* - Currently it has to be set to 'command'.\n-   *name* - Command name. For instance 'step'.\n-   *id* - Optional packet ID. It's just sent back with a response and\n    can be used to pair them.\n\nThe rest of properties are optional.\n\nExamples:\n\n~~~~ {.js}\n{\"type\":\"command\",\"name\":\"step\"}\n{\"type\":\"command\",\"name\":\"set_breakpoint\",\"breakpoint\":{\"url\":\"test.js\",\n\"line\":22}}\n~~~~\n\n### Response\n\nResponse if normalized and consists of the following parts:\n\n-   *type* - Response type: 'error, 'info'. Info for plain responses,\n    error for errors.\n-   *subtype* - Name of the response.\n\nThe rest of the properties are optional.\n\nExamples:\n\n~~~~ {.js}\n{\"type\":\"info\",\"subtype\":\"pc\",\"script\":\"example.js\",\"line\":2,\"source\":null,\n\"id\":\"95D892FEC352D9AF\"}\n~~~~\n\n### Supported commands\n\nStandard parameters described above have been omitted intentionally.\n\n    ----\n\n    Name: pc\n    Description: Gets current program counter.\n    Request:\n        name             - 'pc'\n        source (boolean) - True if current source line (code, not a number)\n                           should be returned in response.\n    Response:\n        subtype  - 'pc'\n        script   - Script's URL.\n        line     - Line number.\n        source   - A line of source code pointed by PC.\n\n    Req: {\"type\":\"command\",\"name\":\"pc\",\"source\":false,\"id\":\"CE2DA6CB1B6AFC7A\"}\n    Res: {\"type\":\"info\",\"subtype\":\"pc\",\"script\":\"example.js\",\"line\":2,\"source\":null,\n         \"id\":\"CE2DA6CB1B6AFC7A\"}\n\n    ----\n\n    Name: step\n    Description: Steps program until it reaches a different source line.\n    Request:\n        name  - 'step'\n    Response: None.\n\n    Req: {\"type\":\"command\",\"name\":\"step\"}\n\n    ----\n\n    Name: next\n    Description: Steps program proceeding through subroutines.\n    Request:\n        name  - 'next'\n    Response: None.\n\n    Req: {\"type\":\"command\",\"name\":\"next\"}\n\n    ----\n\n    Name: continue\n    Description: Continues execution.\n    Request:\n        name - 'continue'\n    Response: None.\n\n    Req: {\"type\":\"command\",\"name\":\"continue\"}\n\n    ----\n\n    Name: stop\n    Description: Terminates a debuggee.\n    Request:\n        name - 'stop'\n    Response: None.\n\n    Req: {\"type\":\"command\",\"name\":\"stop\"}\n\n    ----\n\n    Name: source_code\n    Description: Gets source code for given URL.\n    Request:\n        name  - 'get_source'\n        url   - Script's URL.\n\n    Response:\n        subtype       - 'source_code'\n        script        - Script's URL.\n        source        - Source code.\n        displacement  - Source code displacement, see debugger engine options.\n\n    Example:\n    Req: {\"type\":\"command\",\"name\":\"get_source\",\"url\":\"example.js\",\"id\":\n         \"CCE548813F631269\"}\n    Res: {\"type\":\"info\",\"subtype\":\"source_code\",\"script\":\"example.js\",\"source\":\n         [\"debugger;\",\"...\"],\"displacement\":0,\"id\":\"DFF3E74BE6BF7DD7\"}\n\n    ----\n\n    Name: delete_all_breakpoints\n    Description: Deletes all registered breakpoints.\n    Request:\n        name - 'delete_all_breakpoints'\n\n    Response:\n        subtype - 'all_breakpoints_deleted'\n\n    Example:\n    Req: {\"type\":\"command\",\"name\":\"delete_all_breakpoints\",\n         \"id\":\"6DE62B9327DDEFEA\"}\n    Res: {\"type\":\"info\",\"subtype\":\"all_breakpoints_deleted\",\"id\":\"6DE62B9327DDEFEA\"\n         }\n\n    ----\n\n    Name: pause\n    Description: Pauses debuggee as soon as possible.\n    Request:\n        name - 'pause'\n\n    Response: None\n\n    Example:\n    Req: {\"type\":\"command\",\"name\":\"pause\",\"id\":\"F37C8BF4BCBCEAE4\"}\n\n    ----\n\n    Name: set_breakpoint\n    Description: Registers a new breakpoint.\n    Request:\n        name - 'set_breakpoint'\n\n    Response:\n        subtype - 'breakpoint_set'\n        bid - Numeric breakpoint identifier.\n        url - Script file where breakpoint has been set.\n        line - Line at which breakpoint has been set.\n        pending - False if breakpoint has been already registered, true if it's a\n                  pending breakpoint which waits for the script for being loaded.\n\n    Example:\n    Req: {\"type\":\"command\",\"name\":\"set_breakpoint\",\"breakpoint\":{\n         \"url\":\"/home/tas/workspace_gnome/gjs/examples/gtk.js\",\"line\":2,\n         \"pending\":true}\n    Res: {\"type\":\"info\",\"subtype\":\"breakpoint_set\",\"bid\":0,\n         \"url\":\"/home/tas/workspace_gnome/gjs/examples/gtk.js\",\"line\":2,\n         \"pending\":false,\"id\":\"46287654F429A626\"}\n\n    ----\n\n    Name: delete_breakpoint\n    Description: Deletes given breakpoint.\n    Request:\n        name - 'delete_breakpoint'\n        ids - Array of numeric breakpoints identifiers to be deleted.\n\n    Response:\n        subtype - 'breakpoint_deleted'\n        ids - Array of numeric breakpoints identifiers to be deleted.\n\n    Example:\n    Req: {\"type\":\"command\",\"name\":\"delete_breakpoint\",\"ids\":[1],\n         \"id\":\"9C59281AB28B5678\"}\n    Res: {\"type\":\"info\",\"subtype\":\"breakpoint_deleted\",\"ids\":[],\n         \"id\":\"9C59281AB28B5678\"}\n\n    ----\n\n    Name: get_stacktrace\n    Description: Gets current JSContext stacktrace.\n    Request:\n        name - 'get_stacktrace'\n\n    Response:\n        subtype - 'stacktrace'\n        stacktrace - Array of stacktrace elements.\n            url - Script's URL.\n            line - Line number.\n            rDepth - Stacktrace depth.\n\n    Example:\n    Req: {\"type\":\"command\",\"name\":\"get_stacktrace\",\"id\":\"857B3B96591A5163\"}\n    Res: {\"type\":\"info\",\"subtype\":\"stacktrace\",\"stacktrace\":\n         [{\"url\":\"/home/tas/workspace_gnome/gjs/examples/gtk.js\",\"line\":96,\n         \"rDepth\":0}],\"id\":\"857B3B96591A5163\"}\n\n    ----\n\n    Name: get_variables\n    Description: Get list of variables from given frame.\n    Request:\n        name - 'get_variables'\n        query - Query.\n            depth - Frame depth.\n            options - Retrieving options.\n                show-hierarchy - Evaluates hierarchy of variables.\n                evaluation-depth - How depth to evaluate.\n\n    Response:\n        subtype - 'variables'\n        variables - Array of stack elements.\n            stackElement - Describes variables for given frame.\n                url - Script's URL.\n                line - Source line.\n                rDepth - Frame depth.\n                variables - Array of variables.\n                    name - Name of a variable.\n                    value - Value of the variable.\n\n    Response:\n        subtype - 'stacktrace'\n        stacktrace - Array of stacktrace elements.\n            url - Script's URL.\n            line - Line number.\n            rDepth - Stacktrace depth.\n\n    Example:\n    Req: {\"type\":\"command\",\"name\":\"get_variables\",\"query\":{\"depth\":0,\"options\":{\n         \"show-hierarchy\":true,\"evaluation-depth\":1}},\"id\":\"63DFE5D533FD5EB4\"}\n    Res: {\"type\":\"info\",\"subtype\":\"variables\",\"variables\":[{\n        \"stackElement\":{\"url\":\"/home/tas/workspace_gnome/gjs/examples/gtk.js\",\n        \"line\":96,\"rDepth\":0},\"variables\":[{\"name\":\"name\",\"value\":1}}]}],\n        \"id\":\"63DFE5D533FD5EB4\"}\n\n    ----\n\n    Name: evaluate\n    Description: Evaluates variable.\n    Request:\n        name - 'evaluate'\n        path - Code to evaluate.\n        options - Retrieving options.\n            show-hierarchy - Evaluates hierarchy of variables.\n            evaluation-depth - How depth to evaluate.\n\n    Response:\n        subtype - 'evaluated'\n        result - Evaluation result.\n\n    Example:\n    Req: {\"type\":\"command\",\"name\":\"evaluate\",\"path\":\"toString\",\"options\":\n         {\"show-hierarchy\":true,\"evaluation-depth\":1},\"id\":\"5791287CABE43BF6\"}\n    Res: {\"type\":\"info\",\"subtype\":\"evaluated\",\"result\":{\n         \"___jsrdbg_function_desc___\":{\"displayName\":\"toString\",\"name\":\"toString\",\n         \"parameterNames\":[]},\"length\":0,\"name\":\"toString\",\"arguments\":null,\n         \"caller\":null},\"id\":\"5791287CABE43BF6\"}\n\n    ----\n\n    Name: get_all_source_urls\n    Description: Get list of source scripts handled by a debugger.\n    Request:\n        name - 'get_all_source_urls'\n\n    Response:\n        subtype - 'all_source_urls'\n        urls - Array of script URLs.\n\n    Example:\n    Req: {\"type\":\"command\",\"name\":\"get_all_source_urls\",\"id\":\"AD9CD9D1C76D8EC4\"}\n    Res: {\"type\":\"info\",\"subtype\":\"all_source_urls\",\"urls\":\n         [\"/home/tas/workspace_gnome/gjs/examples/gtk.js\",\"debugger eval code\",\n         \"resource:///org/gnome/gjs/modules/overrides/GLib.js\",\n         \"resource:///org/gnome/gjs/modules/lang.js\"],\"id\":\"AD9CD9D1C76D8EC4\"}\n\n    ----\n\n    Name: get_breakpoints\n    Description: Gets list of all registered breakpoints.\n    Request:\n        name - 'get_breakpoints'\n\n    Response:\n        subtype - 'breakpoints_list'\n        breakpoints - Array of available breakpoints.\n            bid - Numeric breakpoint identifier.\n            url - Script file where breakpoint has been set.\n            line - Line at which breakpoint has been set.\n            pending (boolean) - False if breakpoint has been already registered,\n                      true if it's a pending breakpoint which waits for the script\n                      for being loaded.\n\n    Example:\n    Req: {\"type\":\"command\",\"name\":\"get_breakpoints\",\"id\":\"3E5D8A1A168E11F5\"}\n    Res: {\"type\":\"info\",\"subtype\":\"breakpoints_list\",\"breakpoints\":[{\"bid\":0,\n         \"url\":\"/home/tas/workspace_gnome/gjs/examples/gtk.js\",\"line\":2,\n         \"pending\":false}],\"id\":\"3E5D8A1A168E11F5\"}\n\n    ----\n\n    Name: get_available_contexts\n    Description: Gets list of all handled JSContexts.\n    Request: Plain string: get_available_contexts\\n\n    Response:\n        subtype  - 'contexts_list'\n        contexts - Array of contexts.\n            contextId - Numerical context ID.\n            contextName - Context name, the same which has to be passed to the\n                          install method.\n            paused (boolean ) - True if context is already paused.\n\n    Res: {\"type\":\"info\",\"subtype\":\"contexts_list\",\"contexts\":[{\"contextId\":0,\n         \"contextName\":\"example-JS\",\"paused\":true}]}\n\n    ----\n\n    Name: exit\n    Description: Closes debugger.\n    Request: Plain string: exit\\n\n\n    Common packets:\n\n    Packed sent every time when debugger switches to PAUSED state.\n\n    {\"type\":\"info\",\"subtype\":\"paused\",\n    \"url\":\"/home/tas/workspace_gnome/gjs/examples/gtk.js\",\n    \"line\":2,\"source\":\"const Gtk = imports.gi.Gtk;\"}\n\n    source - Source code line.\n    line - Line number.\n    url - Script's URL.\n\n    Packed sent every time when error occurred.\n    {\"type\":\"error\",\"message\":\"Error message.\",\"code\":1,\"id\":\"65855F75466DA4A6\"}\n\n    message - Textual error message.\n    code - One of the supported error codes:\n\n    ERROR_CODE_UNKNOWN_COMMAND       = 1\n    ERROR_CODE_NO_COMMAND_NAME       = 2\n    ERROR_CODE_NOT_A_COMMAND_PACKAGE = 3\n    ERROR_CODE_NOT_PAUSED            = 4\n    ERROR_CODE_BAD_ARGS              = 5\n    ERROR_CODE_SCRIPT_NOT_FOUND      = 6\n    ERROR_CODE_CANNOT_SET_BREAKPOINT = 8\n    ERROR_CODE_IS_PAUSED             = 9\n    ERROR_CODE_UNEXPECTED_EXC        = 10\n    ERROR_CODE_EVALUATION_FAILED     = 11\n    ERROR_CODE_PC_NOT_AVAILABLE      = 12\n    ERROR_CODE_NO_ACTIVE_FRAME       = 13\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fswojtasiak%2Fjsrdbg","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fswojtasiak%2Fjsrdbg","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fswojtasiak%2Fjsrdbg/lists"}