Changes between Version 11 and Version 12 of JavascriptDebugging


Ignore:
Timestamp:
Jan 23, 2013, 2:34:50 PM (11 years ago)
Author:
Yves
Comment:

--

Legend:

Unmodified
Added
Removed
Modified

  • JavascriptDebugging

    v11 v12  
    44
    55== Technical background ==
    6 The DebuggingServer component makes debugging commands like (ToggleBreakpoint, Step, Continue etc...) available using a mongoose webserver.
    7 The format used for return values is JSON, which should be easy to parse from a Web-GUI.
     6The DebuggingServer component makes debugging commands like (ToggleBreakpoint, Step, Continue etc...) available using a Mongoose webserver.
     7The format used for return values is JSON, which should be easy to parse from a web-GUI.
    88 
    99The Debugger uses the JSDBGAPI provided by Spidermonkey 1.8.5. Newer versions of Spidermonkey provide a simplified new API (along with memory leak fixes, performance improvements and more), but unfortunately Mozilla isn't interested in doing the work and publishing a independent build from Firefox at the moment.
    1010We had a [http://irclogs.wildfiregames.com/2013-01-02-QuakeNet-%230ad-dev.log discussion about that on IRC].
     11We're thinking about upgrading Spidermonkey nevertheless, but that could be a bigger task.
    1112
    1213The JSDBGAPI isn't thread-safe and also our current implementation of ScriptInterfaces (which are basically abstractions of Spidermonkey) isn't thread-safe either.
    13 As a general rule, all Javascript objects are tied to one ScriptInterface which represents one Javascript runtime and one Javascript context and can only be used in one thread. We do use multiple threads, but each of them only uses one ScriptInterface.
     14As a general rule, all Javascript objects are tied to one ScriptInterface which represents one Javascript runtime and one Javascript context and can only be used in one thread (although multiple ScriptInterface can be used in one thread). We do use multiple threads, but they don't share ScriptInterfaces.
    1415One major difficulty about implementing a debugger is not to violate these constraints.
    1516
    16 The idea is that there's one CThreadDebugger class which is responsible for tracking hooks, callbacks, breakpoints and general state information for each of those ScriptInterfaces. The class CDebuggingServer manages multiple threads using multiple objects of CThreadDebugger.
    17 It passes commands from the mongoose webserver (triggered by the user) to the CThreadDebugger objects and retrieves state information from these objects and returns it to the user as JSON. The DebuggingServer makes sure not to access any Spidermonkey functions or Javascript objects directly (because they belong to the ScriptInterface's thread).
     17The idea is that there's one CThreadDebugger class which is responsible for tracking hooks, callbacks, breakpoints and general state information for each of those ScriptInterfaces. The class CDebuggingServer manages multiple ScriptInterfaces (which are potentially multiple threads) using multiple objects of CThreadDebugger.
     18It passes commands from the Mongoose webserver (triggered by the user) to the CThreadDebugger objects and retrieves state information from these objects and returns it to the user as JSON. The DebuggingServer makes sure not to access any Spidermonkey functions or Javascript objects directly (because they belong to the ScriptInterface's thread).
    1819The DebuggingServer itself should also be thread-safe to accept multiple request asynchronously.
    1920
    … …  
    2122== Available commands ==
    2223This section lists all currently implemented commands and gives some examples of data they return.
     24
     25=== Setting: Simultaneously breaking threads ===
     26This setting specifies the behaviour when a breakpoint is hit.
     27If enabled, all other threads executing Javascript code will halt too as soon as possible and their status (ThreadInBreak) will change to true.
     28Keep in mind that other ScriptInterfaces being executed in the same thread will not halt because their code will only be reached when you continue the execution in the current ScriptInterface. Another limitation is that threads can only be halted by this debugger when they execute Javascript code!
     29You can set breakpoints with your favourite c++ debugger at the right places if you need seamless debugging between c++ and Javascript.
     30
     31==== Get ====
     32{{{
     33http://127.0.0.1:9000/GetSettingSimultaneousThreadBreak
     34}}}
     35
     36Returns:
     37{{{
     38#!js
     39{ "Enabled" : true }
     40}}}
     41
     42==== Set ====
     43
     44{{{
     45http://127.0.0.1:9000/SetSettingSimultaneousThreadBreak?Enabled=false
     46}}}
     47Arguments:
     48 * '''Enabled''': If the setting should be enabled (true or false).
     49
     50Returns:
     51Nothing
     52
    2353
    2454=== Toggling (setting/removing) breakpoints: ===
    … …  
    3767{{{
    3868#!js
    39 { "ThreadDebuggerID" : 1,"ScriptInterfaceName" : "GUI","ThreadInBreak" : true,"BreakFileName" : "gui/gamesetup/gamesetup.js","BreakLine" : 1502 }
     69[ { "ThreadDebuggerID" : 1,"ScriptInterfaceName" : "GUI","ThreadInBreak" : true,"BreakFileName" : "gui/gamesetup/gamesetup.js","BreakLine" : 1502 } ]
    4070}}}
    41 
    4271Note:
    4372BreakFileName and BreakLine should be considered "undefined" if ThreadInBreak is false!
    … …  
    4877http://127.0.0.1:9000/Continue?threadDebuggerID=1
    4978}}}
    50 
    5179Arguments:
    52  * '''threadDebuggerID''': The ThreadDebuggerID of the thread that should be continued. You can get this ID by calling GetThreadDebuggerStatus.
     80 * '''threadDebuggerID''': The ThreadDebuggerID of the thread that should be continued. You can get this ID by calling GetThreadDebuggerStatus. If you pass 0, all threads will be continued.
    5381
    5482Returns:
    … …  
    5886
    5987=== Step ===
    60 Step the execution. Honestly I'm not sure what it exactly does at the moment.
    61 After calling it a few times it steps to the next line. Probably it executes each assignment/operation separately.
    62 I will figure it out and improve it for a next patch.
     88Steps to the next line of code and will step over functions that are called on the current line.
    6389{{{
    6490http://127.0.0.1:9000/Step?threadDebuggerID=1
    6591}}}
     92Arguments:
     93 * '''threadDebuggerID''': The ThreadDebuggerID of the thread that should be stepped. You can get this ID by calling GetThreadDebuggerStatus.
    6694
     95Returns:
     96Nothing
     97
     98=== Step into ===
     99Steps into function calls on the current line of code or steps to the next line if there aren't any function calls.
     100{{{
     101http://127.0.0.1:9000/StepInto?threadDebuggerID=1
     102}}}
     103Arguments:
     104 * '''threadDebuggerID''': The ThreadDebuggerID of the thread that should be stepped. You can get this ID by calling GetThreadDebuggerStatus.
     105
     106Returns:
     107Nothing
     108
     109=== Step out ===
     110Steps out of the current function and stops the execution in the parent function.
     111{{{
     112http://127.0.0.1:9000/StepOut?threadDebuggerID=1
     113}}}
    67114Arguments:
    68115 * '''threadDebuggerID''': The ThreadDebuggerID of the thread that should be stepped. You can get this ID by calling GetThreadDebuggerStatus.
    … …  
    77124http://127.0.0.1:9000/GetAllCallstacks
    78125}}}
    79 
    80126Returns:
    81127{{{
    … …  
    91137http://127.0.0.1:9000/GetStackFrame?nestingLevel=0&threadDebuggerID=1
    92138}}}
    93 
    94139Returns:
    95140{{{
    96141... need to find a shorter example ...
    97142}}}
    98 
    99143Arguments:
    100144 * '''nestingLevel''' If you look at the function above (GetCallstack), nestingLevel=0 would point to the innermost stackframe (keywordTestOR). Native functions as "__eventhandler31" don't return any data.
    … …  
    107151http://127.0.0.1:9000/EnumVfsJSFiles
    108152}}}
    109 
    110153Returns (shortened)
    111154{{{
    … …  
    119162http://127.0.0.1:9000/GetFile?filename=globalscripts/Math.js
    120163}}}
    121 
    122164Returns:
    123165A file as plaintext.
    … …  
    125167Arguments:
    126168 * '''filename''' A full Vfs path to a file
    127  
     169
     170
     171
     172== Known issues ==
     173 * Error messages can be displayed caused by StringifyJSON and objects that don't support serialization
     174 * Getting a stack frame and getting the callstack doesn't always work. This will have to be checked more closely soon.
     175 * Some functionality is still missing. Further testing, proper error handling and correcting/completing comments is also required.