weixin_39842682
weixin_39842682
2020-11-30 10:22

Reverse debugging problems on RSDemo/simple Program on Linux w/ VSCode

I'm trying to get reverse debugging working on Ubuntu 16.04.1 x64.

I'm using VSCode nightlies and node chakracore nightlies. I've tried many recent versions of Node Chakra core (using nvs) but cannot get reverse debugging to work. I'm able to get step forward debugging working but doing a step backwards or even a play (forwards) results in an error condition (see below).

I find ttlog is consistently empty.


node --debug-brk=4904 --nolazy -TTRecord:ttlog -TTBreakFirst app.js 
Debugger listening on 127.0.0.1:4904
Server running on http://127.0.0.1:3000
TTD assert failed: We missed something!!!

I'm able to make more progress by simply recording a "Hello World" type simple script from the command-line. This time ttlog does fill up with files but trying to debug it in vscode fails.

When I try to debug, I'm not able to break on the first line and the debugger simply exits like so:


node --debug-brk=24509 --nolazy -TTDebug:ttlog -TTBreakFirst testing.js 
Debugger listening on 127.0.0.1:24509
Reached end of Execution -- Exiting.

The script looks like this:


function hello() {
  console.log("hello world");
  return 3 + 4;
}

hello();

I don't know how useful this is but the debugger tries to stop at


EventEmitter.prototype.emit = function emit(type) {
  var er, handler, len, args, i, events, domain;
/* TRIES TO STOP HERE */  var needDomainExit = false;
  var doError = (type === 'error');

  events = this._events;
  if (events)
...
...

and then just exits...

Node Version: v7.0.0-nightly20161229ddd22d6204, Ubuntu 16.04.1 x64 code-insider-1.9.0-1482995608_amd64

cc:

该提问来源于开源项目:nodejs/node-chakracore

  • 点赞
  • 写回答
  • 关注问题
  • 收藏
  • 复制链接分享
  • 邀请回答

8条回答

  • weixin_39842682 weixin_39842682 5月前

    This time I had more success: - I recorded the HelloWorld trace on the command line. The program terminates normally and so the trace gets written out nicely - I am able to debug the HelloWorld trace on VSCode. What was lacking was a --debug in my runtimeArgs originally. Once that was instituted, things work. - If you install a SIGINT signal handler in app.js to capture the signal and then do a process.exit() the trace log appears without any issues for RSDemo also.

    A minor suggestion: The sample record/replay application is a typescript application -- thats great because it shows off the fact the record/replay works with sourcemaps. But it would be better, I think, to have a plain vanilla JS application. By having typescript it just confuses people. Of course, typescript can be totally ignored and we can deal with the js files but the debugger in VSCode automatically goes to the .ts files. Also, debugger movements on .ts files can sometimes be confusing and unexpected due to limitations with true execution mapping between .ts and .js.

    点赞 评论 复制链接分享
  • weixin_39842682 weixin_39842682 5月前

    I have some questions, thanks for all your help so far in getting this to work finally:

    FYI, we don't support mixing record mode with the interactive debugger yet so the approach you take with separate record then replay is the only currently supported option.

    No promises and commitments, of course, but: - Is this feature under development? If so, when is it likely to land? Is it already present in ChakraCore? - In general what are the limitations of doing record/replay in NodeChakraCore vs simply ChakraCore. Is debugging via VSCode/any other tool possible in just plain vanilla ChakraCore?

    we do not start recording until this code completes and the runtime moves into the event loop callbacks.

    I'm wondering if it were better that, by default, each recording is a faithful rendition of what exactly node.js did. I may want to investigate what happened in node before the first callback fired.

    I was looking for rcbo (Reverse callback to origin) referred to in section 2.3 https://www.microsoft.com/en-us/research/wp-content/uploads/2016/09/TTNode.pdf

    Is that currently not implemented in VSCode+NodeChakraCore integration? Is it possible to use that in ChakraCore already?

    点赞 评论 复制链接分享
  • weixin_39616961 weixin_39616961 5月前

    Great I am glad that things are working.

    Thanks for the feedback on the SIGINT handler and TypeScript vs javaScript for the sample. Going forward I would like to build up a set of samples including both TypeScript and JavaScript based programs. It is also good to have your input on when we start the recording. This is something we will definitely re-consider as we get more experience.

    On the longer term roadmap questions: - An interactive debugger mode is something we want to have but there is no timeframe for this. The current plan is to focus on stability and features around the record/replay scenarios and then invest in interactive debugging scenarios. - ChakraCore doesn't directly support the VSCode Node debugger protocol. So, right now we can record/replay traces in ChakraCore for testing but it isn't usable for debugging. In theory VSCode debugging could be implemented for ChakraCore but this hasn't been done yet. - The rcbo feature isn't available in VSCode yet. We implemented a prototype but there are 2 issues which are currently blocking us. First is we need to detect all the async registrations/invocations in a Node application and this a topic that is currently in flux (see the Tracing Working Group). Second, each new operation we add requires some new UI and we aren't quite happy with how to expose things (e.g., we don't want to have a UI with a huge number of new debugger operation buttons).

    I am personally very excited about the many things we can potentially do with the underlying TTD technology but we want to get experience and feedback to make sure the features we add are also useful for developers.

    点赞 评论 复制链接分享
  • weixin_39842682 weixin_39842682 5月前

    I think rcbo would be killer feature as far as node chakra core is concerned (just like reverse debugging is already). In fact the whole point of node is async and reverse debugging without being able to trace back through the callback potentially hamstrings reverse debugging a bit I think. But yes, I agree that its important to iron out what you've built rather than introduce new features before the older ones have stabilized. Regarding UI -- I think VSCode is a far more flexible platform than, say, Classic Visual Studio. VSCode is built for rapid iteration given its JavaScript innards. In summary I think the reverse debugging story (especially with something like rcbo in the mix in future) is probably one of the biggest things that will make a user consider shifting from traditional V8 node to node chakra-core.

    Yes indeed, the sky is the limit with the kind of things one can do with a robust reverse debugging framework. There is so much to reverse debugging apart from reverse debugging.

    点赞 评论 复制链接分享
  • weixin_39616961 weixin_39616961 5月前

    Added info to --help and checks for appropriate usage in PR #180.

    点赞 评论 复制链接分享
  • weixin_39616961 weixin_39616961 5月前

    Hi, on the first issue when running with "-TTRecord:ttlog -TTBreakFirst app.js". The -TTBreakFirst flag is intended to only be used when in debug mode "-TTDebug" and will error out if used in other modes (e.g. issue #159). FYI, we don't support mixing record mode with the interactive debugger yet so the approach you take with separate record then replay is the only currently supported option.

    On the second issue, since startup code is easy to re-run and generally involves a lot of (uninteresting) initialization work we do not start recording until this code completes and the runtime moves into the event loop callbacks. So, in your example there is no user script execution in the recording (and it exits immediately). I modified your sample code (below) to include execution during the event loop and verified that I can set breakpoints which are hit.

    
    function hello() {
      console.log("hello world");
      return 3 + 4;
    }
    
    setTimeout(hello, 10); /*added setTimeout instead of direct call*/
    

    Thanks for reporting these problems. I'll open a PR shortly to add better usage messages. Please let us know if you have any other issues or questions.

    P.S. during replay console.log messages are suppressed (do not write to the console) so we have a special telemetryLog(msgString, boolWriteFlag) function which will write a string message during both record and replay when the boolWriteFlag is true.

    点赞 评论 复制链接分享
  • weixin_39842682 weixin_39842682 5月前

    Thanks for your helpful comments.

    Hi, on the first issue when running with "-TTRecord:ttlog -TTBreakFirst app.js". The -TTBreakFirst flag is intended to only be used when in debug mode "-TTDebug" and will error out if used in other modes (e.g. issue #159). FYI, we don't support mixing record mode with the interactive debugger yet so the approach you take with separate record then replay is the only currently supported option.

    When I remove the -TTBreakFirst command now and do a plain -TTRecord, I still stop on breakpoints. I'm guessing this a VSCode issue as it tries to establish breakpoints when it connects to the debugger. So VSCode is defeating the ability to do a record here inadvertently perhaps?

    However even after removing all breakpoints from VSCode it does not seem to help because ttlog still is empty.

    I figured that maybe VSCode is somehow interfering and I tried to do this on my bash shell

    
    $ node --nolazy -TTRecord:ttlog app.js 
    

    The server runs fine but again I'm not able to see anything in ttlog after ceasing recording. I end recording by pressing Ctrl+C -- perhaps that is not the correct approach?

    I also got this message at some point though I don't remember why.

    
    node --debug-brk=40440 --nolazy -TTRecord:ttlog app.js 
    Debugger listening on 127.0.0.1:40440
    Server running on http://127.0.0.1:3000
    TTD assert failed: Empty stack!
    

    I modified your sample code (below) to include execution during the event loop and verified that I can set breakpoints which are hit.

    Sorry, strangely enough I'm not able get the TTDebug working on hello world even after the timeout setup. I see VSCode simply trying to show the debugging bar momentarily before it disconnects again. (This happens whether or not TTBreakFirst option is there)

    Minor nitpick: there is a --nolazy with two dashes but simply -TTRecord -TTDebug with one dash. I think both one and two dash options should be allowed. Also it should be case insensitive so something like -ttdebug does not work currently.

    点赞 评论 复制链接分享
  • weixin_39616961 weixin_39616961 5月前

    Hi, I have updated Issue #159 to include some of the unsupported debugger/recording interactions you are seeing. I have also opened Issue #162 on writing a log with ctrl-c which seems to be a common request.

    On the issues you are seeing I just finished syncing my Linux instance to the same setup you have. Dropping my download of the nightly node-chakracore files and the HelloWorld sample program directory on my desktop I ran the following: cd ~/Desktop/node-v7.0.0-nightly/bin ./node --nolazy -TTRecord:ttlog ~/Desktop/HelloWorld/app.js

    Then I set my .vscode launch.json configuration as follows:

    
    {
        "name": "Launch",
        "type": "node",
        "request": "launch",
        "program": "${workspaceRoot}/app.js",
        "cwd": "/home/mark/Desktop/node-v7.0.0-nightly/bin/",
        "runtimeExecutable": "/home/mark/Desktop/node-v7.0.0-nightly/bin/node",
        "runtimeArgs": [
            "--nolazy",
            "--debug",
            "-TTDebug:ttlog",
            "-TTBreakFirst" 
        ],
        "env": {
            "NODE_ENV": "development"
         },
        "console": "internalConsole"
    }
    

    Using this configuration I can set a breakpoint on line 4 (that is return 3 + 4). After launching I see the breakpoint getting hit (although VSCode has the call stack one frame up and I need to manually click on the "hello" frame in the "Call Stack" window) and can step back as well.

    My suspicion is there is something in the configuration above that we did not document clearly. So, hopefully this will clear up the issue. Please let me know if it does (and what it is so we can fix it) or if there are other problems.

    Thanks.

    点赞 评论 复制链接分享

相关推荐