harold-b / vscode-duktape-debug Goto Github PK

Hello,

I have a TypeScript project with the below directory structure (stripped down for brevity):

<root>
|__samples
|  |__sample1
|  |  |__src
|  |  |  |__... (TypeScript source files and directories)
|  |  |__tsconfig.json
|  |__sample2
|  |  |__... (similar layout to 'sample1')
|  |__sample3
|     |__... (similar layout to 'sample1')
|__src
|  |__... (TypeScript source files and directories)
|__tsconfig.json

The rationale behind the layout is that everything under the base src directory corresponds to the API of the project, while everything under samples correspond to very specific examples indicating how to use the API. Each sample has a src directory containing TypeScript source files, and a corresponding tsconfig.json. Those tsconfig.json files look as follows (again, stripped down for brevity):

{
  "compilerOptions": {
    "sourceMap": true,
    "outDir": "../../build/out-tsc/sample1",
    "baseUrl": "src",
    "paths": {
      "*": [
        "./*",
        "../../../src/*"
      ]
    }
  }
}

Specifically, we use the baseUrl and paths compiler options to reference the source code both in the sample (./*) and the API (../../../src/*) directories. Using this, the output directory (../../build/out-tsc/sample1) winds up looking something:

<root>/build/out-tsc/sample1
|__samples
|  |__sample1
|     |__src
|        |__... (JavaScript sources and source maps)
|__src
   |__... (JavaScript sources and source maps)

In light of this, what's the proper way to configure this debugger to work with this setup? I've tried a number of things to no avail, and I guess it boils down to my misunderstanding of some of the properties. Specifically, I have this in my launch.json:

{
  "name": "Duk Attach (Sample1)",
  "type": "duk",
  "request": "attach",
  "stopOnEntry": false,
  "address": "localhost",
  "port": 9091,
  "localRoot": "${workspaceRoot}",
  "sourceMaps": true,
  "outDir": "${workspaceRoot}/build/out-tsc/sample1",
  "debugLog": false
}

But I don't see how this can make sense. outDir points to the root of the sample1 output, but the source files in that directory are spread out in two different sub-directories (at odd locations no less).

I've hacked the debugger to get this setup to work by using multiple search paths for searching for files, but it isn't production quality (or really sustainable). I'm also wondering if I even need to hack the debugger, or if this is something that could be supported with the current debugger implementation.

So... any ideas? I'm also open (to a certain degree) to changing my directory structures if necessary. Any help would be appreciated.

(Please consider that I'm not really a Node developer, so if any of the above looks odd or non-standard, it wasn't intentional.)

While I can now set breakpoints before launching my app and without a wait loop (which was necessary before), I now see a new disturbing behavior. When vscode is launched freshly and I set a breakpoint, everything's going well. The debugger stops at the breakpoint. This works as long no error occured during a run. At some point the debugger starts to open an unrelated source file (usually from the node modules) but quickly switches back to the original source file with the breakpoint. Once an error occurs (or maybe other reasons I haven't spotted) this back switch no longer happens and the debugger stops at a line in that unrelated sourcefile. I can then do a step-in or step-over to end up again at the real source location. The wrong source file is also opened then without an active breakpoint. I'm constantly closing unrelated tabs now after each debugger run.

And as if that wasn't odd enough, after some debugger runs, it also fails to show any variables. That means I can not inspect any values nor is the VARIABLES section populated. Switching stack entries in the stacktrace leads to an error saying the right stackframe could not be determined. At this point I have to restart vscode to get back to a usable debugging behavior again.

Currently only the "attach" request setting is accepted for debugging a duktape application. It would however be much more convenient to have the debugger also launch the application to debug. Constantly having to manually start the application before starting a debugging run is tiring.

When using the Duktape.Logger mechanism, any statements I log are logged to stdout with carriage returns at the end, but in VSCode they don't, although other statements do.

It would be good if this could be updated

I use the duktape api duk_peval_file() this sends the full path to the .js file to the debugger, but the path on my target platform does not match my local directory.

The default duktape debugger can have a list of source search paths, and it strips the file path off the string and attempts to match the file name in the supplied list of paths.

It would be great if this functionality could be added to vscode-duktape-debug. Or maybe just strip the path, and search recursively under "localRoot"

Right now, I have had to modify duktape to push the filename only which then works correctly with the debugger

Hi,

A number of pull requests have been accepted, but the debugger has not be released since March 2017. Any chance you could release the current master. I've been holding off on updating our platform to a newer Duktape due to incompatibilities.

Many thanks

I was getting an error, and tracked down the problem this the following line:

DukDbgProtocol.ts Line: #204

if( msg.length != 7 )
    throw new Error( "Invalid 'BasicInfo' response message." );

This is found inside the constructor of the DukBasicInfoResponse class. It seems on my implementation of DukTape, msg only has a length of 6, so I was getting that error thrown.

When I change it to check for a length of 6, then the debugger attaches and I start getting console logs from my JavaScript.

Hi,

We are trying to run the vscode with duktape application in remote. On breakpoints, call stack is displayed with line numbers.But, for every frame in callstack is showing "Unknown Source". Any suggestions on how to proceed further?.

Thanks.

Regards,
Madan

I've been working for a while without issues with my duktape running on the localhost, and so nice and quick, but now I have deployed duktape to an ARM based target board with IP over USB so the whole thing is a bit slower, and this has uncovered a number of issues.

I'm using "stopOnEntry": true to work around the fact that sometimes code runs before the break points are set, when I 'Attach', the code is correctly stopped at the top of the JavaScript file. I then set a breakpoint and hit 'Resume'. The code runs and the breakpoint is hit, but VS Code still thinks it is running i.e. 'Pause' button is available, not 'step' or 'resume'. If I press 'Pause' I get 'Request failed: Already paused.'

Debug log is as follows:

Establishing connection with Duktape at 192.168.1.80:9091
Connected. Verifying protocol...
Protocol: 1 10600 v1.6.0 SW terminal
Requesting target info...
OUT -> <REQ: 1> <0x10: BASICINFO>
Status Notification: PAUSE
IN <- <REP: 2> <int: 10600> <str: v1.6.0> <str: SW terminal> <int: 1> <int: 4> <EOM: 0>
10600 v1.6.0 SW terminal Little
Attached to duktape debugger.
Finalized Initialization.
removeAllTargetBreakpoints
OUT -> <REQ: 1> <0x17: LISTBREAK>
[FE] setBreakPointsRequest
IN <- <REP: 2> <EOM: 0>
OUT -> <REQ: 1> <0x18: ADDBREAK>
IN <- <REP: 2> <int: 0> <EOM: 0>
OUT -> <REQ: 1> <0x12: PAUSE>
[FE] configurationDoneRequest
[FE] threadsRequest
IN <- <REP: 2> <EOM: 0>
Status Notification: PAUSE
[FE] threadsRequest
[FE] stackTraceRequest
OUT -> <REQ: 1> <0x1c: GETCALLSTACK>
IN <- <REP: 2> <str: message_box.js> <str: eval> <int: 1> <int: 0> <EOM: 0>
OUT -> <REQ: 1> <0x1e: EVAL>
IN <- <REP: 2> <int: 0> <str: [object global]> <EOM: 0>
[FE] scopesRequest
OUT -> <REQ: 1> <0x1d: GETLOCALS>
IN <- <REP: 2> <EOM: 0>
OUT -> <REQ: 1> <0x1e: EVAL>
IN <- <REP: 2> <int: 0> <str: [object global]> <EOM: 0>
[FE] variablesRequest
[FE] setBreakPointsRequest
OUT -> <REQ: 1> <0x18: ADDBREAK>
IN <- <REP: 2> <int: 1> <EOM: 0>
[FE] continueRequest
OUT -> <REQ: 1> <0x13: RESUME>
IN <- <REP: 2> <EOM: 0>
Status Notification: PAUSE
[FE] threadsRequest
[FE] stackTraceRequest
OUT -> <REQ: 1> <0x1c: GETCALLSTACK>
IN <- <REP: 2> <str: message_box.js> <str: > <int: 5> <int: 0> <str: message_box.js> <str: eval> <int: 153> <int: 4> <EOM: 0>
OUT -> <REQ: 1> <0x1e: EVAL>
IN <- <REP: 2> <int: 0> <str: undefined> <EOM: 0>
OUT -> <REQ: 1> <0x1e: EVAL>
IN <- <REP: 2> <int: 1> <str: TypeError: cannot read property 'constructor' of undefined> <EOM: 0>
OUT -> <REQ: 1> <0x1e: EVAL>
IN <- <REP: 2> <int: 0> <str: [object global]> <EOM: 0>
[FE] scopesRequest
OUT -> <REQ: 1> <0x1d: GETLOCALS>
IN <- <REP: 2> <str: APPMGR> <tval: undefined> <str: list> <tval: undefined> <str: messageBox> <tval: undefined> <str: AppId> <tval: undefined> <str: listId> <tval: undefined> <str: info> <tval: undefined> <str: inputText> <tval: undefined> <str: listContent> <tval: undefined> <str: listData> <tval: undefined> <EOM: 0>
OUT -> <REQ: 1> <0x1e: EVAL>
IN <- <REP: 2> <int: 0> <str: undefined> <EOM: 0>
OUT -> <REQ: 1> <0x1e: EVAL>
IN <- <REP: 2> <int: 0> <tval: undefined> <EOM: 0>
OUT -> <REQ: 1> <0x1e: EVAL>
IN <- <REP: 2> <int: 0> <tval: undefined> <EOM: 0>
OUT -> <REQ: 1> <0x1e: EVAL>
IN <- <REP: 2> <int: 0> <tval: undefined> <EOM: 0>
OUT -> <REQ: 1> <0x1e: EVAL>
IN <- <REP: 2> <int: 0> <tval: undefined> <EOM: 0>
OUT -> <REQ: 1> <0x1e: EVAL>
IN <- <REP: 2> <int: 0> <tval: undefined> <EOM: 0>
OUT -> <REQ: 1> <0x1e: EVAL>
IN <- <REP: 2> <int: 0> <tval: undefined> <EOM: 0>
OUT -> <REQ: 1> <0x1e: EVAL>
IN <- <REP: 2> <int: 0> <tval: undefined> <EOM: 0>
OUT -> <REQ: 1> <0x1e: EVAL>
IN <- <REP: 2> <int: 0> <tval: undefined> <EOM: 0>
OUT -> <REQ: 1> <0x1e: EVAL>
IN <- <REP: 2> <int: 0> <tval: undefined> <EOM: 0>
OUT -> <REQ: 1> <0x1e: EVAL>
IN <- <REP: 2> <int: 0> <tval: undefined> <EOM: 0>
[FE] variablesRequest

After updating Visual Studio to 1.9.0 the default debug configuration is no longer populated. I assumed this was an issue with VSCode (microsoft/vscode#20332), but when I raised an issue there, I was informed that a change is needed in vscode-duktape-debug.

Please file this against the duktape debugger here https://github.com/harold-b/vscode-duktape-debug
And let them know they need to implement configuration snippets as node is doing https://github.com/Microsoft/vscode-node-debug/blob/master/package.json#L98

With the latest extension version (0.5.6) I get now an error when I debug my own extension.:

Activating extension `HaroldBrenes.duk-debug` failed:  e.resume is not a function
extensionHostProcess.js:506
Here is the error stack:  TypeError: e.resume is not a function
	at S.start (/Users/mike/.vscode/extensions/haroldbrenes.duk-debug-0.5.6/dist/extension.js:1:64530)
	at Function.run (/Users/mike/.vscode/extensions/haroldbrenes.duk-debug-0.5.6/dist/extension.js:1:15675)
	at Object.<anonymous> (/Users/mike/.vscode/extensions/haroldbrenes.duk-debug-0.5.6/dist/extension.js:1:38869)
	at n (/Users/mike/.vscode/extensions/haroldbrenes.duk-debug-0.5.6/dist/extension.js:1:186)
	at /Users/mike/.vscode/extensions/haroldbrenes.duk-debug-0.5.6/dist/extension.js:1:985
	at Object.<anonymous> (/Users/mike/.vscode/extensions/haroldbrenes.duk-debug-0.5.6/dist/extension.js:1:995)
	at Module._compile (/Applications/Visual Studio Code.app/Contents/Resources/app/out/vs/loader.js:15:749)
	at Object..js (internal/modules/cjs/loader.js:798:10)
	at Module.load (internal/modules/cjs/loader.js:645:32)
	at Function.<anonymous> (internal/modules/cjs/loader.js:560:12)
	at Function.<anonymous> (/Applications/Visual Studio Code.app/Contents/Resources/app/out/vs/workbench/services/extensions/node/extensionHostProcess.js:796:719)
	at Function.<anonymous> (/Applications/Visual Studio Code.app/Contents/Resources/app/out/vs/workbench/services/extensions/node/extensionHostProcess.js:765:302)
	at Function._load (/Applications/Visual Studio Code.app/Contents/Resources/app/out/vs/workbench/services/extensions/node/extensionHostProcess.js:761:870)
	at Module.require (internal/modules/cjs/loader.js:685:19)
	at require (internal/modules/cjs/helpers.js:16:16)
	at Function.s [as __$__nodeRequire] (/Applications/Visual Studio Code.app/Contents/Resources/app/out/vs/loader.js:32:963)
	at d._loadCommonJSModule (/Applications/Visual Studio Code.app/Contents/Resources/app/out/vs/workbench/services/extensions/node/extensionHostProcess.js:766:484)
	at d._doActivateExtension (/Applications/Visual Studio Code.app/Contents/Resources/app/out/vs/workbench/services/extensions/node/extensionHostProcess.js:677:300)
	at d._activateExtension (/Applications/Visual Studio Code.app/Contents/Resources/app/out/vs/workbench/services/extensions/node/extensionHostProcess.js:676:360)
	at Object.actualActivateExtension (/Applications/Visual Studio Code.app/Contents/Resources/app/out/vs/workbench/services/extensions/node/extensionHostProcess.js:674:296)
	at Object._activateExtension (/Applications/Visual Studio Code.app/Contents/Resources/app/out/vs/workbench/services/extensions/node/extensionHostProcess.js:506:21)
	at /Applications/Visual Studio Code.app/Contents/Resources/app/out/vs/workbench/services/extensions/node/extensionHostProcess.js:505:632
	at Array.map (<anonymous>)
	at Object._activateExtensions (/Applications/Visual Studio Code.app/Contents/Resources/app/out/vs/workbench/services/extensions/node/extensionHostProcess.js:505:620)
	at Object.activateByEvent (/Applications/Visual Studio Code.app/Contents/Resources/app/out/vs/workbench/services/extensions/node/extensionHostProcess.js:503:413)
	at d._activateByEvent (/Applications/Visual Studio Code.app/Contents/Resources/app/out/vs/workbench/services/extensions/node/extensionHostProcess.js:675:24)
	at /Applications/Visual Studio Code.app/Contents/Resources/app/out/vs/workbench/services/extensions/node/extensionHostProcess.js:683:293

Additionally I get:

(node:97525) [DEP0005] DeprecationWarning: Buffer() is deprecated due to security and usability issues. Please use the Buffer.alloc(), Buffer.allocUnsafe(), or Buffer.from() methods instead.
warning.js:27
(node:97525) [DEP0005] DeprecationWarning: Buffer() is deprecated due to security and usability issues. Please use the Buffer.alloc(), Buffer.allocUnsafe(), or Buffer.from() methods instead.
warning.js:27

though I don't know if that is throw for the duktap-debug extension or comes from something else.

When I attach the debugger and set a breakpoint in VS Code, the point goes grey and says "Unverified Breakpoint". I believe I have set up my launch config correctly pointing to the right localRoot etc.

I am using JavaScript not TypeScript, and here is my launch config:

{
	"version": "0.2.0",
	"configurations": [
		{
			"name": "Attach",
			"type": "duk",
			"request": "attach",
			"address": "localhost",
			"port": 9091,
			"localRoot": "${workspaceRoot}",
			"sourceMaps": false,
			"outDir": null,
			"stopOnEntry": false
		}
	]
}

This could be an issue at the DukTape side, or maybe a problem with the extension not finding the source folder?

If a breakpoint is set in the start of script with "stopOnEntry": false, the code runs before the breakpoint is set. It works ok with "stopOnEntry": true. The log appears to show a breakpoint being set after the resume command

Log as follows:

Establishing connection with Duktape at 192.168.1.80:9091
Connected. Verifying protocol...
Protocol: 1 10600 v1.6.0 Sepura terminal
Requesting target info...
OUT -> <REQ: 1> <0x10: BASICINFO>
Status Notification: PAUSE
IN <- <REP: 2> <int: 10600> <str: v1.6.0> <str: Sepura terminal> <int: 1> <int: 4> <EOM: 0>
10600 v1.6.0 Sepura terminal Little
Attached to duktape debugger.
Finalized Initialization.
removeAllTargetBreakpoints
OUT -> <REQ: 1> <0x17: LISTBREAK>
[FE] setBreakPointsRequest
IN <- <REP: 2> <EOM: 0>
OUT -> <REQ: 1> <0x18: ADDBREAK>
IN <- <REP: 2> <int: 0> <EOM: 0>
OUT -> <REQ: 1> <0x13: RESUME>
IN <- <REP: 2> <EOM: 0>
OUT -> <REQ: 1> <0x18: ADDBREAK>

I'm interesting in using the vscode duktape debugger, but I'm having trouble getting it working.

It does connect to my target, but no breakpoints are ever hit.

• I've installed the latest Visual Studio Code and duk-debugger extension
• I've downloaded duktape 1.5.1 and built the commandline tool with debug (make -f Makefile.dukdebug)
• I can run duktape with the included javascript file (duk --debugger mandel.js)
• I open the duktape folder in VS Code
• Open the mandel.js file and add some breakpoints
• I created a default 'Duk Attach' configuration
• When I hit start debugging, the debugger attaches, the code runs and I can see the output in the console, and then it detaches again, but never hits the breakpoints

I have tried doing the same thing with the the browser based debugger that comes with duktape, and that works correctly.

Any help you can give would be greatly appreciated.

Similarly like in #6 and #13 I have trouble with breakpoints. I'm also using the example TCP/IP code (debug-trans-socket, the unix code running on macOS) to add debug support to my test application. It's waiting for a debug connection and vscode can attach to it. However, it never stops on break points. It doesn't matter if I set "stopOnEntry" to true or false. However when I enable that setting vscode seems to be in an unconsistent state. It's still running (I can see the protocol output when setting/removing a breakpoint) but I cannot hold the execution (the Pause icon is enabled but does nothing when I click it). However, I see log output when I do:

[FE] pauseRequest
OUT -> <REQ: 1> <0x12: PAUSE>
IN <- <REP: 2> <EOM: 0> 

But that doesn't help much when the execution is not interrupted. Any idea what's missing to make break points work?

Btw: I also have added that wait loop at the start of my script, just in case, but that doesn't help either.

Some additional info:
I can make the debugger break on the debugger command in JS. I even can step through the code, but there is no line highlight showing me where I am actually. I only see the call stack and variables.

I am trying to get the debugger working with the following version of the duktape runtime:

• Git commit: 458018a88649ec249f47737aeb2807616167cfd9
• Git describe: v1.5.0-1123-g458018a
• Git branch: master

The connection is established, but I get a disconnect almost immediately on the following stack:

cmdline.exe!duk_debug_write_eom(duk_hthread * thr) Line 39121	C
cmdline.exe!duk__debug_do_detach1(duk_heap * heap, int reason) Line 38222	C

cmdline.exe!duk_debug_read_int(duk_hthread * thr) Line 38507 C
cmdline.exe!duk__debug_read_validate_csindex(duk_hthread * thr) Line 39325 C
cmdline.exe!duk__debug_handle_eval(duk_hthread * thr, duk_heap * heap) Line 39665 C
cmdline.exe!duk__debug_process_message(duk_hthread * thr) Line 40614 C
cmdline.exe!duk_debug_process_messages(duk_hthread * thr, int no_block) Line 40788 C
cmdline.exe!duk__interrupt_handle_debugger(duk_hthread * thr, int * out_immediate, unsigned int * out_interrupt_retval) Line 69168 C
cmdline.exe!duk__executor_interrupt(duk_hthread * thr) Line 69289 C

It seems that the runtime doesn't expect the int that it got from the debugger.
Is it possible that the version that I use is incompatible with version 0.2.8 of the debugger?

If so, which version should I be using, I couldn't find any versioning information.

Thanks, Andrey.

Hi @harold-b !

I wonder if you could help me out. I'm hitting some problems setting breakpoints on Windows in my project. Everything is working great on Mac/Linux but the following code is causing issues when mapping source files with absolute paths/drive letters:

From sourceMaps.ts in SouceMap constructor

  for (let i = 0; i < sm.sources.length; i++) {
            sm.sources[i] = this.toUrl(sm.sources[i]);
        }

I'm hitting "Unknown source file" issues as a result of finding no matches in DukDebugger.ts scanDir.

This is happening because of the "file:///" prefix added to source paths containing drive letters in the toUrl function. The below comparison fails as a result:

DukDebugger.ts:2121

if (this.normPath(Path.resolve(this._outDir, candidateFile)) === path)

In my case at DukDebuffer.ts:2121 the debugger shows:

candidateFile="file:///d:/Development/Proj/Software/External/Libraries/blueprint/examples/GainPlugin/Source/jsui/src/Slider.js"

path="d:\Development\Proj\Software\External\Libraries\blueprint\examples\GainPlugin\Source\jsui\src\Slider.js"

Is this prefix to be expected here? Currently this comparison will always fail.

My webpack config uses the following source-map configuration:

 devtoolModuleFilenameTemplate: info =>
    `webpack:///${info.absoluteResourcePath.replace(/\\/g, '/')}`

In my outDir I have a single main.js and a single main.js.map file. Source paths in my map appear as below:

"webpack:///D:/Development/Proj/Software/External/Libraries/blueprint/examples/GainPlugin/Source/jsui/src/Slider.js"

My workspaceFolder/root is at D:/Development/Proj/Software/External/Libraries/blueprint/examples/GainPlugin/Source/jsui

Launch.json is as follows:

{
    // Use IntelliSense to learn about possible attributes.
    // Hover to view descriptions of existing attributes.
    // For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
    "version": "0.2.0",
    "configurations": [
        {
            "name": "Attach (duk)",
            "type": "duk",
            "request": "attach",
            "address": "localhost",
            "port": 9091,
            "localRoot": "${workspaceFolder}",
            "sourceMaps": true,
            "outDir": "${workspaceFolder}/build/js",
            "stopOnEntry": true,
            "debugLog": true
        }
    ]

OK, being able to connect, pause the debugger and see the local variable and add watches.
Still however cannot get the sources to show, when I pause I get "Source Unknown Source Unavailable" in the file window, and in the stack I see the functions being called, but get "\undefined\Source Unavailable" tooltip.
Obviously I am doing something wrong, but cannot figure out what.
Tried switching the the following code:
#if 0
if (duk_peval_string(ctx, js.c_str()) != 0) {
printf("eval failed: %s\n", duk_safe_to_string(ctx, -1));
exit(-1);
}
#else
duk_push_string(ctx, "input.js");
duk_compile_string_filename(ctx, 0, js.c_str(), );

duk_push_global_object(ctx);
duk_call_method(ctx, 0);

#endif
So that the execution environment knows about the filename, and I have the same file open VSCode, but nothing help.
Any pointers appreciated.

Also Harold I see that the print statements are forwarded to the debugger in your demo, how does that work?

Thanks, Andrey.

I am finally making the jump from Duktape v1.6.1 to v2.1.1 and I'm having issues getting the debugger to work now.

What I'm seeing is that the debugger attaches, but the source file is not reported, no breakpoints are hit, and the VS Code UI reports that it is running despite having requested it to stopOnEntry

I'm using:

• vscode: 1.15.1
• vscode-duktape-debug: 0.4.1

My test is as follows:

• built the duk.exe command line tool (supplied with duktape 2.1.1), with debug and print support
• run duk.exe --debugger mandle.js
• attach from vscode-duktape-debug

Launch file:

"configurations": [
    {
        "name": "Attach",
        "type": "duk",
        "request": "attach",
        "address": "localhost",
        "port": 9091,
        "localRoot": "${workspaceRoot}",
        "sourceMaps": false,
        "outDir": null,
        "stopOnEntry": true,
        "debugLog": true
    }
]

Debug log:

Attached to duktape debugger.
Protocol ID: 2 20101 external unknownFinalized Initialization.
removeAllTargetBreakpoints
OUT -> <REQ: 1> <0x17: LISTBREAK>
IN <- <NFY: 4> <int: 7> <str: DebuggerHandleFile> <str: mandel.js> <EOM: 0> 
Status Notification: PAUSE
IN <- <REP: 2> <EOM: 0> 
OUT -> <REQ: 1> <0x12: PAUSE>
IN <- <REP: 2> <EOM: 0> 
[FE] setBreakPointsRequest
OUT -> <REQ: 1> <0x18: ADDBREAK>
IN <- <REP: 2> <int: 0> <EOM: 0> 
OUT -> <REQ: 1> <0x18: ADDBREAK>
IN <- <REP: 2> <int: 1> <EOM: 0> 
OUT -> <REQ: 1> <0x18: ADDBREAK>
IN <- <REP: 2> <int: 2> <EOM: 0> 
[FE] configurationDoneRequest
[FE] threadsRequest

I ran the same version of the vscode-duktape-debug against a version 1.6.0 duk.exe app, and it worked without issue:

Attached to duktape debugger.
Protocol ID: 1 10600 v1.6.0 unknownIN <- <NFY: 4> <int: 7> <str: DebuggerHandleFile> <str: mandel.js> <EOM: 0> 
Finalized Initialization.
removeAllTargetBreakpoints
OUT -> <REQ: 1> <0x17: LISTBREAK>
Status Notification: PAUSE
IN <- <REP: 2> <EOM: 0> 
OUT -> <REQ: 1> <0x12: PAUSE>
IN <- <REP: 2> <EOM: 0> 
Status Notification: PAUSE
[FE] setBreakPointsRequest
OUT -> <REQ: 1> <0x18: ADDBREAK>
IN <- <REP: 2> <int: 0> <EOM: 0> 
OUT -> <REQ: 1> <0x18: ADDBREAK>
IN <- <REP: 2> <int: 1> <EOM: 0> 
OUT -> <REQ: 1> <0x18: ADDBREAK>
[FE] threadsRequest
IN <- <REP: 2> <int: 2> <EOM: 0> 
[FE] stackTraceRequest
OUT -> <REQ: 1> <0x1c: GETCALLSTACK>
IN <- <REP: 2> <str: mandel.js> <str: global> <int: 8> <int: 0> <EOM: 0> 
OUT -> <REQ: 1> <0x1e: EVAL>
[FE] configurationDoneRequest
[FE] threadsRequest
IN <- <REP: 2> <int: 0> <str: [object global]> <EOM: 0> 
[FE] scopesRequest
OUT -> <REQ: 1> <0x1d: GETLOCALS>
IN <- <REP: 2> <EOM: 0> 
OUT -> <REQ: 1> <0x1e: EVAL>
IN <- <REP: 2> <int: 0> <str: [object global]> <EOM: 0> 
[FE] variablesRequest

This suggests something is missing from the initialisation when using Duktape 2 protocol, maybe these:

OUT -> <REQ: 1> <0x1c: GETCALLSTACK>
OUT -> <REQ: 1> <0x1d: GETLOCALS>

In order to confirm the debugger is the issue I have also run the node duk_debug.js Duktape debugger, and it worked as expected, note this makes the GetCallStack request:

Scanning source files: ..\
Found 0 source files in 1 search directories
Connecting to 127.0.0.1:9091...
Listening on *:9092
Debug transport connected
Socket.io connected
Debug version identification: 2 20101 external unknown
Debugger attached
Request BasicInfo: REQ 16 EOM
Notify AppNotify: NFY 7 "DebuggerHandleFile" "mandel.js" EOM
Unknown notify, ignoring: NFY 7 "DebuggerHandleFile" "mandel.js" EOM
Notify Status: NFY 1 1 "mandel.js" "global" 8 0 EOM
Request ListBreak: REQ 23 EOM
Request GetLocals: REQ 29 -1 EOM
Request GetCallStack: REQ 28 EOM
Reply for BasicInfo: REP 20101 "external" "unknown" 1 8 EOM
Reply for ListBreak: REP EOM
Reply for GetLocals: REP EOM
Reply for GetCallStack: REP "mandel.js" "global" 8 0 EOM
Source list request
Source request:
Source request: mandel.js

When I enable the log for the duktape-debugger extension I get (among others) this output:

OUT -> <REQ: 1> <0x1c: GETCALLSTACK>
IN <- <REP: 2> <str: main.js> <str: global> <int: 10> <int: 26> <str: eval> <str: > <int: 1> <int: 1> <EOM: 0>
OUT -> <REQ: 1> <0x1e: EVAL>
IN <- <REP: 2> <int: 0> <str: undefined> <EOM: 0>
OUT -> <REQ: 1> <0x1e: EVAL>
IN <- <REP: 2> <int: 1> <str: TypeError: cannot read property 'constructor' of undefined> <EOM: 0>
OUT -> <REQ: 1> <0x1e: EVAL>
IN <- <REP: 2> <int: 0> <str: [object global]> <EOM: 0>
[FE] scopesRequest
OUT -> <REQ: 1> <0x1d: GETLOCALS>
IN <- <REP: 2> <EOM: 0>
OUT -> <REQ: 1> <0x1e: EVAL>
IN <- <REP: 2> <int: 0> <str: undefined> <EOM: 0>
OUT -> <REQ: 1> <0x1e: EVAL>
IN <- <REP: 2> <int: 0> <tval: undefined> <EOM: 0>
[FE] variablesRequest

How can I find out what is actually missing (that undefined)? I tried debugging this in duktape/C but couldn't get what that undefined is actually supposed to be.

built make -f makefile.dukdebug as is using gcc in windows
\duktape-2.2.1>.\duk --debugger -i mandel.js

Attached to duktape debugger.
Protocol ID: 2 20201 external unknownFinalized Initialization.
removeAllTargetBreakpoints
OUT -> <REQ: 1> <0x17: LISTBREAK>
IN <- <NFY: 4> <int: 7> <str: DebuggerHandleFile> <str: mandel.js> <EOM: 0>
Status Notification: PAUSE
IN <- <REP: 2> <EOM: 0>
OUT -> <REQ: 1> <0x13: RESUME>
[FE] setBreakPointsRequest
[FE] setBreakPointsRequest
IN <- <REP: 2> <EOM: 0>
OUT -> <REQ: 1> <0x18: ADDBREAK>

{
"name": "Attach",
"type": "duk",
"request": "attach",
"address": "localhost",
"port": 9091,
"localRoot": "${workspaceRoot}",
"sourceMaps": false,
"outDir": "${workspaceRoot}",
"stopOnEntry": false,
"debugLog": true
}

The new "debugLog" property shoes in the IDE as 'Not allowed' I guess a schema needs updating somewhere. Also when creating a debug configuration, this is not included by default, it would be good if it was with a default value of false.

It would be nice to have an option that would hide properties named with DUK_HIDDEN_SYMBOL() macro. I think it should be enabled by default, because such properties are meant to be hidden from end users.

[edit] My bad, I see this issue has been logged as duktape#1292, please disregard.

In my code I often have the need to store large strings. Currently the debugger closes with Disconnected: The receive buffer overflowed., so I tried to increase the buffer size in the local JS code I have in the extension (DukDbgProtocol.js), by setting:

DukDbgProtocol.IN_BUF_SIZE = 1024 * 1024 * 16; 

which is 16MB (much larger than the initial 16KB). Still, this doesn't solve my problem. I restarted vscode to ensure it picks up the JS changes, but to no avail. What else can I do?

The title doesn't fully describe what I see, because after all I can see all variables and their values. But how they are presented in the debugger is quite strange (I'm using duktape 2.1.0). You can see this especially in the tooltip for a variable (which not only shows the value of the variable but also the names of other variables).

When you use the DEBUG CONSOLE to print a value it starts like this (I ran interfaces there):

First problem: what on earth is that { cls: 1 ...} trying to tell me? Can this be switched off please?
Second problem: there is no value printed for the variable interfaces.

However, this weird object containing cls has some content:

Third problem: it lists all available variables, not just the one I want to see.
Forth problem: __artificial, I know it's showing internal stuff from duktape, but that isn't needed all the time. Can this please switched off?

While breakpoints work fine for files that are parsed before the main script starts I have problems with such files which are loaded at runtime. The situation is I have a testing framework which enumerates files on disk and loads them with require() to execute them.

Not only does no breakpoint hold there, even the debugger command doesn't work correctly. It stops but the shown position is somewhere in a file that was loaded normally.

Is this again a filename issue? The test files are loaded by the same mechanism as any other module and there breakpoints work. So it's hard to see the filename problem applying here. The debug log is:

Attached to duktape debugger.
Protocol ID: 2 20100 external unknownIN <- <NFY: 4> <int: 7> <str: DebuggerHandleFile> <str: main.js> <EOM: 0> 
Finalized Initialization.
removeAllTargetBreakpoints
OUT -> <REQ: 1> <0x17: LISTBREAK>
Status Notification: PAUSE
IN <- <REP: 2> <EOM: 0> 
OUT -> <REQ: 1> <0x13: RESUME>
IN <- <REP: 2> <EOM: 0> 
[FE] setBreakPointsRequest
OUT -> <REQ: 1> <0x18: ADDBREAK>
IN <- <REP: 2> <int: 0> <EOM: 0> 
[FE] configurationDoneRequest
[FE] threadsRequest
Status Notification: PAUSE
[FE] threadsRequest
[FE] stackTraceRequest
OUT -> <REQ: 1> <0x1c: GETCALLSTACK>
IN <- <REP: 2> <str: main.js> <str: global> <int: 27> <int: 26> <str: eval> <str: > <int: 1> <int: 1> <EOM: 0> 
OUT -> <REQ: 1> <0x1e: EVAL>
IN <- <REP: 2> <int: 0> <str: undefined> <EOM: 0> 
OUT -> <REQ: 1> <0x1e: EVAL>
IN <- <REP: 2> <int: 1> <str: TypeError: cannot read property 'constructor' of undefined> <EOM: 0> 
OUT -> <REQ: 1> <0x1e: EVAL>
IN <- <REP: 2> <int: 0> <str: [object global]> <EOM: 0> 
[FE] scopesRequest
OUT -> <REQ: 1> <0x1d: GETLOCALS>
IN <- <REP: 2> <EOM: 0> 
OUT -> <REQ: 1> <0x1e: EVAL>
IN <- <REP: 2> <int: 0> <str: undefined> <EOM: 0> 
OUT -> <REQ: 1> <0x1e: EVAL>
IN <- <REP: 2> <int: 0> <tval: undefined> <EOM: 0> 
[FE] variablesRequest
[FE] setBreakPointsRequest
OUT -> <REQ: 1> <0x18: ADDBREAK>
IN <- <REP: 2> <int: 1> <EOM: 0> 
[FE] continueRequest
OUT -> <REQ: 1> <0x13: RESUME>
IN <- <REP: 2> <EOM: 0> 
...
[FE] disconnectRequest

What I did was:

• set a breakpoint in the main script
• run
• breakpoint is hit
• add a breakpoint in the file which gets dynamically loaded
• continue
• entire run ended without hitting the second breakpoint

As you can see there is type error in this log, which however has nothing to do with this breakpoint problem. However, I have yet to figure out what the problem here is. The constructor of what is actually missing (and why is it needed)?

I build some typescript and bundle in to a single script, which I then run on duktape, however the filename in duktape may have a prefix, which causes the debugger to fail to match filenames.

For example my bundled file might be bundle.js directly in my outDir, but duktape records the file as subdir/bundle.js. When I add a breakpoint in the debugger, it tells duktape to add a breakpoint on the bundle.js file, which duktape can't find.

There may be a better way to solve this, but this is my initial thought.

hi!

this addon works fine!

but the key used to debug are 'conflict' with vscode.
the 'debug' key functions classic <f7,f8,..> don't works! property =[

on question:
duk_reattach is property supported?

Hi, this extension of vscode connect directly on app (duktape engine with debugger support) OR via nodejs/proxy ?

Thanks for clarify any.

PS: i.e., what is the scene to uses it succefully.

I'm getting an exception on print statements when running with --debugger and either stepping through or running the code in the VS Code debugger.

$ ./duk --debugger mandel.js 
Debugger enabled, create socket and wait for connection
Waiting for debug connection on port 9091

From VS Code, I can step through the code, set break point, but duk is throwing an exception when hitting a print statement. This runs fine without the --debugger switch

Here's the exception:

Exception has occurred: Error
ReferenceError: print is not defined
    at Object.<anonymous> (Code/duktape/mandel.js:52:5)
    at Module._compile (module.js:413:34)
    at Object.Module._extensions..js (module.js:422:10)
    at Module.load (module.js:357:32)
    at Function.Module._load (module.js:314:12)
    at Module.runMain [as _onTimeout] (module.js:447:10)
    at Timer.listOnTimeout (timers.js:92:15)

Anyone else experiencing this issue?
I've just installed/built duktape and the VS Code debugger, so I am new to this.
Using duktape version 2.5.0.

I have this figured out. The problem was, in VS Code, I ran Launch Program instead of running Attach(duk). These are both configurations in launch.json.

By watching the order in which certain functions are called via debug messages (using continueRequest() as the test case), when things are fine requestResume().then() is called before a status notification event indicating a paused state occurs. When the UI locks up the notify happens first.

I've encountered this with typescript code as simple as:

class EmptyClass { }
function main() {
    let t = new EmptyClass();
}

The debugger can step through code just fine for declaring/using standard variables, It also handles function calls just fine from what I can tell (even a call to a static function in a class), but I keep getting an "Unexpected end of JSON input" error whenever a class tries to instantiate.

Something additional you might find interesting:

class StaticFunction {
    static example() { let t = 0; }
}

function main() {
    StaticFunction.example();
}

If I step the debugger into the example() static function and try to expand the "this: Function" local variable, the same error occurs. I was able to get a screencap before the UI was nuked:

That ÿ is interesting. Doing a quick search on that character and JSON files yielded me these:
http://stackoverflow.com/questions/30596681/json-parsing-unexpected-character-%C3%BF-at-position-0
http://stackoverflow.com/questions/37294273/failed-to-parse-template-error-parsing-json-invalid-character-%C3%BF-looking-for

Not sure how applicable it is here but it feels like it could relevant.

Hi,

First thanks for the great extension I've learned a lot about vscode development by reading through the code.

I'm wondering you accepting PRs to this repo? From earlier comments it looks like you don't have much time to spend on it. Have noticed koush has forked and published this extension with fixes (I've raised a couple of PRs to his repo also).

I think it would be good to have a single extension published so if you are looking for maintainers then please let me know and hopefully we can merge his fork. I intend to add tests and ci in a feature branch of my fork this week to ease the maintainence burden and make it easier for people to contribute.

Many thanks.

Team,

I am trying to integrate VSCode with duktape, with the vscode-duktape-debug plugin . We are facing below problem :

1,On clicking a object within a structure, values are displayed as heapptr and not as absolute values.

Eg:
id : <cls : 6, ptr : 0x0000000001fabc40> and not printing the actual value.

2,Also, we sometimes facing a problem where vscode console is showing error as below:

document not defined in document.event call from bluebird.js:835

Please share if you have any suggestions on this.

Thanks.

Regards,
Madan

I am not sure if this is a bug in the debugger extension or a limitation of Duktape itself, but it seems that virtual properties, defined like below, are not getting listed during object inspection in variables/watch windows.

duk_push_string(ctx, propertyName);
duk_push_c_function(ctx, getterFunction, 0);
duk_push_c_function(ctx, setterFunction, 1);
duk_def_prop(ctx, -4, DUK_DEFPROP_HAVE_GETTER | DUK_DEFPROP_HAVE_SETTER);

It is possible to inspect such properties, but they need to be explicitly referenced in the watch window or the debug console (e.g. obj.myVirtualProperty).

I think it would make sense if virtual properties were listed in the same way as regular ones.

The file paths which get stored with the breakpoints have a lowercase drive letter when set pre-attach.
Breakpoints set post-attach have uppercase drive letters.
The file path that's compared against in getBreakpointsForFile() has an uppercase drive letter.
This causes the string compare in getBreakpointsForFile() to fail on breakpoints set pre-attach.

Ultimately the duktape debugger still sees these breakpoints even though vscode doesn't and acts on them accordingly (there's also no way to clear them since vscode doesn't see them).

Temp solution on my fork is just doing .toLowerCase() during the comparison but it's obviously not optimal.

Is doRemoveBreakpoints accounting for the fact that the duktape breakpoint indices are going to shift after the request is processed? If so, how? I can't quite work it out.

Hi,

We noticed your extension in package.json is using a "initialConfigurations" contribution in a deprecated way by specifiying a command id.
We wanted to let you know that we plan to delete support for this specific use of "initialConfigurations" soon.
More about this deprecation can be found here and in our release notes.
A good example on how to use the DebugConfigurarationProvider which is the new way of doing this can be found here

Also note other deprecations which are specified in our release notes (which can be found on our site).

Kind regards,
Isidor from the VSCode team

I'm not sure if this is actually a duktape issue or one from the debug adaptor. Let me know and I open an issue against duktape if necessary.

The problem I have is that in vscode I see no properties of objects created with the duktape API (normal JS objects are shown fine). Instead I always get something like { cls: 1, ptr: 0x00007ff82d419640 }. Also such objects do not appear in the VARIABLES section.

However the objects are valid. I can query values from them if I know the key (from the DEBUG CONSOLE:

Attached to duktape debugger.
Protocol ID: 2 20100 external unknownIN <- <NFY: 4> <int: 7> <str: DebuggerHandleFile> <str: main.js> <EOM: 0> 
Finalized Initialization.
removeAllTargetBreakpoints
OUT -> <REQ: 1> <0x17: LISTBREAK>
Status Notification: PAUSE
IN <- <REP: 2> <EOM: 0> 
OUT -> <REQ: 1> <0x13: RESUME>
IN <- <REP: 2> <EOM: 0> 
[FE] setBreakPointsRequest
OUT -> <REQ: 1> <0x18: ADDBREAK>
IN <- <REP: 2> <int: 0> <EOM: 0> 
[FE] configurationDoneRequest
[FE] threadsRequest
Status Notification: PAUSE
[FE] threadsRequest
[FE] stackTraceRequest
OUT -> <REQ: 1> <0x1c: GETCALLSTACK>
IN <- <REP: 2> <str: main.js> <str: global> <int: 12> <int: 35> <EOM: 0> 
OUT -> <REQ: 1> <0x1e: EVAL>
IN <- <REP: 2> <int: 0> <str: [object global]> <EOM: 0> 
[FE] scopesRequest
OUT -> <REQ: 1> <0x1d: GETLOCALS>
IN <- <REP: 2> <EOM: 0> 
OUT -> <REQ: 1> <0x1e: EVAL>
IN <- <REP: 2> <int: 0> <str: [object global]> <EOM: 0> 
[FE] variablesRequest

env
{ cls: 1, ptr: 0x00007f95b45165f0 }

[FE] evaluateRequest
Expression: env
OUT -> <REQ: 1> <0x1e: EVAL>
IN <- <REP: 2> <int: 0> <tval: { cls: 1, ptr: 0x00007f95b45165f0 }> <EOM: 0> 

env.SHELL
/bin/bash

[FE] evaluateRequest
Expression: env.SHELL
OUT -> <REQ: 1> <0x1e: EVAL>
IN <- <REP: 2> <int: 0> <str: /bin/bash> <EOM: 0> 

The JS code is just: var env = process.env; (process.env behaves like the same property in NodeJS).