search

microsoft / nodejstools

Node.js Tools for Visual Studio
http://aka.ms/explorentvs
Apache License 2.0
1.79k stars 359 forks source link

Remote Debugging - Unable to attach #116

Closed drcrook1 closed 8 years ago

drcrook1 commented 9 years ago

Hello,

There are really a few issues here.

  1. Biggest: Can't attach. I have node running on an intel Edison. I have deployed the RemoteDebug.js and my application along with modules. Those all match my local code. I execute node RemoteDebug.js app.js , it subsequently starts. I then go to attach from VS, which fails. The failure is a silent one. Breakpoints are not hit, the output from the Edison's console is: remoteserverconnected, remoteserverdisconnected.
  2. flags for waitforattach and breakatentrypoint do not function. It just starts going right away.

It did successfully work ~1 month ago. I made no changes to code. I did update the Edison's OS to a newer version however.

mousetraps commented 9 years ago

Not sure how much help I can be, as I'm not familiar with the Intel Edison, but let's give it a whirl :smiley:

  1. "remoteserverconnected" and "remoteserverdisconnected" are not coming from anything in the NTVS codebase... are there any other messages available in ntvs, or the node cmd line? Does it work if you launch without debugging?
  2. Check out the related comments in #1328 on codeplex
drcrook1 commented 9 years ago

Hello, About the Edison: It is a system on a chip, it is similar to a Raspberry Pi, it runs Yocto Linux (no idea). Runs node with bindings to c libraries. I have actually had this tool working previously.

  1. The code actually runs and functions great both ways. RemoteDebugger launches it, I can see messages launching from the debugger kicking off, I cracked open the code to view the flow it is taking and it is going through connected then disconnected. It just doesn't stay connected for debugging. This is the biggest issue.
  2. This looks awesome, I'll write feedback after a demo this morning. I put my parameters in the wrong order, and the ping=0 looks like a cool trick. I'll let you know how it goes. This is useful as I intend to write some new drivers for the Edison in the Cylon library and set up scripts are really difficult to hit without this.
drcrook1 commented 9 years ago

Looks like I was able to get this working on my Edison with a new Edison and a fresh new image. I believe the other Edison may have a corrupt image.

That said, there are some areas of improvement that would be nice. I am not seeing populated types in javascript, I get breakpoints, but no real insight into the values of objects coming back. Example: Console, expanded, does not display that "log" is an option within it. I was wondering what this might be a limitation of (tool, tooling, or does this work on other applications).

drcrook1 commented 9 years ago

OH, BTW, that waitforattach works now that args are in the right order and is super badass!

mousetraps commented 9 years ago

Happy to hear you got it working :smiley: I see log in the populated list - mind taking a screenshot?

mousetraps commented 9 years ago

And we should totally document #ping=0 once and for all

billti commented 9 years ago

Yeah, we should really document that #ping=0 thing :wink:

mousetraps commented 8 years ago

@billti someday :stuck_out_tongue_winking_eye:

mjbvz commented 8 years ago

Added documentation for #ping=0 to wiki on remote debugging: https://github.com/Microsoft/nodejstools/wiki/Advanced-Debugging