Fix #15: debugging session closes silently #23
Conversation
|
I am waiting for the original reporter of this problem to test that this fix closes #15. |
| if (debuggerStatus === (DebuggerStatus.running as DebuggerStatus)) { | ||
| await new Promise<void>((resolve) => setTimeout(resolve, 500)); // Wait for a fraction of a second more, to allow TCP/IP port to initialize in probe-rs-debugger | ||
| } |
There was a problem hiding this comment.
Not directly related to this PR, but what is the reason to use a TCP connection by default?
It seems easier to me to just use stdout to communicate, which requires less setup.
There was a problem hiding this comment.
This is how I originally had it. I discovered it became unstable (mostly lost requests/responses), which were not reproducible over TCP.
Once I made the changeover, I also found it opened the opportunity to pipe RUST_LOG output to the user's VSCode console, so I figured it was worth the extra effort at extension development time.
What do you mean "requires less setup"?
There was a problem hiding this comment.
With stdout, I would assume that that we don't need to wait for any setup, and it would also not be required to find a suitable port to communicate.
The logs are sent to stderr AFAIk, so catching them should still be possible.
There was a problem hiding this comment.
Yep, like I said, that is how I had it working. I implemented the TCP by default based on some posts I found where other extension developers saw similar instability with the STDIO version.
There was a problem hiding this comment.
I'm a bit surprised that STDIO is unstable, but have no reason to doubt it :)
Could you add a comment to explain this? Just to avoid similar questions in the future. Thanks!
| if (debuggerStatus === (DebuggerStatus.running as DebuggerStatus)) { | ||
| await new Promise<void>((resolve) => setTimeout(resolve, 500)); // Wait for a fraction of a second more, to allow TCP/IP port to initialize in probe-rs-debugger | ||
| } |
There was a problem hiding this comment.
I'm a bit surprised that STDIO is unstable, but have no reason to doubt it :)
Could you add a comment to explain this? Just to avoid similar questions in the future. Thanks!
|
bors r+ |
|
Build succeeded: |
This fix for #15 includes the following:
code, also check for the possibility of a processsignal.probe-rs-debuggerprocess was started withchild_process.execFile, which has a defaultmaxBufferfor stdio of1024 * 1024. When the stdout or stderr (RUST_LOG output is handled this way) exceeded this, VSCode would terminate the process and truncate the output ... and because we didn't test thesignal, we never saw theSIGTERMevent happening, and it looked as if theprobe-rs-debuggerfailed silently. I have changed this to usechild_process.spawn, which usesStreamobjects instead ofBufferobjects to handle the stdio from the child process.