Cannot attach debugger to script about clearscript HOT 6 CLOSED

Hi @Muchaszewski,

Thank you very much for providing such detailed information. Our initial thoughts:

1. In your first clip, the script debugger waits for your test program to respond, but it can't, as it's stopped at a managed breakpoint. You then resume the program, but it stops immediately at another breakpoint. Note that connecting the script debugger involves the exchange of several client-server messages. That may take much longer than it takes to run your test program. Note also that connecting the script debugger does not pause script execution. Given all that, it isn't surprising that, when you resume your test program again, it exits before the debugger can complete the connection process, leading to the VSCode error message.

2. In your second clip, something does appear to have gone wrong. The script debugger is connected, but it can't access the loaded scripts. This looks like a ClearScript bug, but we still can't reproduce it. We've tried loading several large scripts as well as a large number of small ones, and VSCode always seems to work, although connecting can take a long time with a large number of scripts in memory.

Question: Can you easily reproduce this issue (the one in your last clip)? Does it happen if you run your application without the managed debugger?

Thanks!

from clearscript.

Hi @ClearScriptLib

This issue on second clip does happen without debugger connected and with Release as the target. I have 100% reproducibility, with multiple examples from my current codebase.

I have managed to create simplified code that on my machine creates the similar error.

using System.Dynamic;
using System.Text;
using System.Threading;
using Microsoft.ClearScript.V8;

public class Program
{
    private static V8ScriptEngine Engine;

    private static void Main(string[] args)
    {
        Engine = new V8ScriptEngine(V8ScriptEngineFlags.EnableDebugging |
                                    V8ScriptEngineFlags.EnableRemoteDebugging);

        var timeout = 0;
        while (timeout < 200)
        {
            Thread.Sleep(5);
            timeout += 1;
        }

        Engine.AddHostObject("foo", new Foo());
        var script = new StringBuilder();
        script.AppendLine("var element = [];");
        for (var i = 0; i < 1201; i++) //Every value below or equal 1200 works
        {
            script.AppendLine("element.push(foo.bar({complex: \"element\"}));");
        }
        Engine.Execute(script.ToString());

        Engine.Execute("debugger;");
    }

    public class Foo
    {
        public DynamicObject bar(DynamicObject obj)
        {
            //Yes I know this could be simplified :)
            Engine.Execute("var __obj__ = {complex2: \"element2\", complex3: 3};");
            return Engine.Script.__obj__;
        }
    }
}

On my machine error shows only when you put more than 1200 into for loop that generates the first script. As you will run this code you will see that the problem is connected not to the long script but a number of additional scripts executions that inside Foo object.

This bug at least on my machine is not executed with normal execution of multiple files one after another.

        for (var i = 0; i < 1201; i++)
        {
              //Works fine for me
              Engine.Execute("var __obj__ = {complex2: \"element2\", complex3: 3};");
        }

Sometimes when I connect I have encountered something a bit different instead of not able to access any documents I receive following message in VSCode:

sourceRequest error: illegal handle

I will also add that this is working in 5.4 with legacy debugger connection.

from clearscript.

Hi @Muchaszewski,

Thanks for posting your sample code. Unfortunately we still can't reproduce the issue, even when we raise the iteration count to 15000.

Our procedure:

1. Set a breakpoint at var timeout = 0; and launch the program.
2. When the breakpoint is hit, connect VSCode.
3. Resume the program immediately.

At this point VSCode connects and stops at debugger;. All scripts are loaded and accessible. Of course, they're all identical, but there's no issue displaying any of them.

Unlike the legacy debugging protocol, which is based on raw socket communications, Inspector is based on HTTP and WebSocket. Is it possible that you're running an aggressive web security product, or some other web traffic monitor that might be interfering?

Thanks!

from clearscript.

Hi @ClearScriptLib

I just have tried using a different machine with much more power.

It seems like this is dependant on machine specification, not network specific. Same thing on the mobile internet, or without internet access, also from different PC with the same/similar processor. I can provide more detailed specification if you wish.
On Intel i5-4460 with 16Gb of ram, this limit is 1201.
On Intel i5-4470 with 16Gb of ram this limit is more dynamic but around 1400 the same story.
On my private machine i7-4790k with 16Gb ram, the limit is set much higher than that, but still existing. 15000 is working "fine" but a little bit higher (the precise number would be hard to estimate) around 16000 same thing happens. I had almost instant results with 15k where 16k didn't finish after 15 minutes of waiting.

If you are using even better processor please put this number higher as there is definitely an issue or use some low spec laptop, although I think this is more connected to VSCode, not ClearSciprt and highly depend on some resources like maximum instruction stack size available to the processor and stack overflow exception is handled in some bugged way.

My thought is right now to allow programmatically from ClearSciprt to decide which documents debugger should consider "downloading" for debugging process, but this is just a workaround, not a solution.

Thanks for all the support so far! Do you think there is any hope for my low spec work PC to be able to handle debugging with 5.5+ ClearScript?

EDIT: My other idea is maybe you have a better way of creating new dynamic JavaScript objects from C# code then Engine.Evaluate(...) which would make me workaround this issue.

from clearscript.

Hi @Muchaszewski,

Hmm. On i7-6700K/16GB we successfully connected several times with the iteration count at 30000. However, it took a long time, during which we were in a state similar to what you saw. Eventually VSCode woke up and allowed us to view the loaded scripts, set breakpoints, etc.

However, sometimes VSCode remained in that state even after the debugger statement was correctly processed. That is, we could tell that script execution had paused (by looking at VSCode's debugging toolbar), but we couldn't view the scripts or do anything else.

During several attempts VSCode because unresponsive. A few times it crashed. It could be that VSCode has scalability issues in this area.

Have you tried Chrome DevTools? Currently ClearScript instances don't show up on chrome://inspect, but you can use an extension such as Node.js V8 Inspector to attach Chrome DevTools to ClearScript. We just tried it several times with the iteration count at 50000, and it worked every time, albeit quite slowly.

Even if you find a debugger that works for you, we strongly recommend that you avoid creating so many scripts. V8 handles it fairly well, but it has its own limits, and the debuggers clearly aren't designed for it.

Our recommendation is to minimize the number of times you invoke V8's parser. Reuse script code you've already parsed. For example, if you need to create many JavaScript objects from C#, create one function and call it as many times as necessary:

dynamic createJsObject = engine.Evaluate("(function () { return {}; })");

var jsObjects = new object[100];
for (var i = 0; i < 100; ++i) {
    jsObjects[i] = createJsObject();
}

You can also create compiled scripts, which you can re-execute without recompilation. These techniques will ease debugging and improve your application's performance.

Good luck!

from clearscript.

@ClearScriptLib thank you for your time and great support.

Since I need only to create JavaScript objects from Json string I will do as you said to create one method that will create for me JavaScript objects using a precompiled method.

//This execute once
var parseToJson = Engine.Compile("function __parseToJson(json) { return JSON.parse(json)}");
Engine.Execute(parseToJson);
//We can now execute this method everywhere in the program
var jsObject = Engine.Invoke("__parseToJson", jsonString);

Also Node.js V8 Inspector works but with migration to 5.5. I will wait until the addition of "wait for debugger".

Thanks again.

from clearscript.