GDB debugger is killed when new vfs worker is started.

[nightwing]

#11 (comment)

[nightwing]

Apparently process.unref at https://github.com/c9/c9.ide.run.debug/blob/master/debuggers/socket.js#L118 doesn't have any effect because detached argument is missing and it's stdio is attached to the parent process. https://nodejs.org/api/child_process.html#child_process_options_detached

[nightwing]

@danallan for gdb debugger netproxy is not actually a proxy, but the runner itself.
Aside from not working after reload, not working for multiple clients, using lsof makes startup very slow, and errors that cause netproxy crash are not visible to user.

I think we need to change the way gdb is launched:

• runner should have something like c9gdblauncher $file $args instead of gdbserver $file $args
• c9gdblauncher will be expanded to node ./pathtovfscache/netproxy.js
• netproxy.js will spawn gdbserver with stdio: "inherit" gdb (like now but without using lsof), and start a server listening on ~/.c9/gdbdebugger.socket.
  (gdbserver is needed to provide tty to the debugged process and not trigger warning about controlling tty from gdb)
• client will wait for a server on ~/.c9/gdbdebugger.socket without any proxy.

What do you think?

[danallan]

Thanks for the follow-up, @nightwing! I like this idea, and I agree that moving what is now a misnamed "netproxy" is the right call. But in this scenario, wouldn't a script named c9gdblauncher need to be installed in the PATH on the user's workspace (which would be problematic for those that use the C9 SDK offline since this wouldn't be pre-installed)? Or, perhaps I am misunderstanding the second bullet; how would c9gdblauncher "expand" to node ./pathtovfscache/netproxy.js?

And, so I'm understanding properly -- the communication between gdb and gdbserver would still occur via local TCP port?

[nightwing]

for the second point to work i'll need to add code to localfs to retrieve the script and place it in ~/.c9 folder (the same mechanism will be used for vfs extensions).
The sdk could use netproxy.js file directly to make debugging easier.

I couldn't find a way to make gdbserver use named pipe, so it most likely have to use TCP port.

[danallan]

This sounds great. What is the timeframe for adding the localfs retrieval code? In the meantime, I can start to rework netproxy to support this change.

[danallan]

Any updates on localfs modifications, @nightwing ? It turns out that having a c9gdblauncher command will be very useful in other contexts for us, as well, so we have a continued interest in restructuring in this way (not to mention the benefits to reliability)!

[danallan]

Most steps completed in #40, except for c9gdblauncher will be expanded to node ./pathtovfscache/netproxy.js. The PR simply writes the old netproxy (now called shim.js to more accurately reflect its design) to a fixed point on the filesystem, but this should be easy enough to change once there's a localfs retrieval mechanism!

In the end, even as implemented in #40 (without localfs retrieval) it largely addresses the original issues described initially.