OS: Windows 10 Pro Version 1703
VS Code version 1.16.0
C/C++ extension version 0.13.0
I am using cpptools with WSL as described here. When I run the debugger, if I place a breakpoint after a printf statement, the output is not displayed in the debug console. I can then run -exec call printf("test\n"), and still no output is produced. Output only shows up if and when the program exits naturally.
Is this expected behaviour?
@Dimpl I've noticed that unless you append a newline at the end, it doesn't seem to flush the buffer. Unfortunately I've noticed this running under just gdb also so I think it is a gdb issue and external to the extension.
I've had issues in the past with te buffer, so I'm careful to place newline characters on all of my testing printfs.
A seemingly related issue comes up with interactive programs. I tried to input to stdin with -exec , but get the error 'Unable to perform this action because the process is running.'. I don't have any issues when running in gdb (not through the vscode debugger).
@Dimpl If you are using -exec in the debugger console, we send what you enter after it directly to gdb. This was to enable passthrough commands to gdb, but the limitation was that we had to make sure gdb was in a stopped/paused state to do it. Therefore we check to see if the degger is stopped and if it isn't, we return the message you are seeing.
I see this issue with program output not being flushed when using cppvsdbg as well. I'm manually flushing stdout in my logging functions to work around it at the moment. stderr appears unbuffered by default.
@pieandcakes Does this mean that the piped debugger will not work on processes which read from stdin? Is there an alternative? I read about attaching to an existing process, but haven't tried this.
@Dimpl It sounds like for your scenario probably not. You can attach to an existing process through pipe but I don't think you can send it stdin input either. You can pass an argument to your program and use a text file piped back into your program to give it lines of input for execution.
The -exec command is to send it gdb commands. if there is a gdb command that can accomplish this, you can send it using -exec
I tried running the program as a separate process and using the 'attach' option, but it would hang after I selected the process from the dropdown, so I was unable to investigate further.
I have also had this issue.
I specify the debuggerPath in my launch.json file and it works!
"debuggerPath": "stdbuf -i0 -o0 -e0 /usr/bin/gdb"
stdbuf here is used to disable buffer of all three channels.
This issue has been closed automatically because it's labeled as 'external'.
Most helpful comment
I specify the debuggerPath in my launch.json file and it works!
"debuggerPath": "stdbuf -i0 -o0 -e0 /usr/bin/gdb"
stdbuf here is used to disable buffer of all three channels.