Can not wait for user input

[jgueytat]

$ gdb --version GNU gdb (Debian 8.2.1-2+b3) 8.2.1

I get the program running properly with the terminal. In VSCode the prorgam does not wait for the user input.

[jgueytat]

https://github.com/gitpod-io/gitpod/issues/3566 May be the report should go on VSCode side.

[jgueytat]

I was only able to get the user input properly with ms-vscode.cpptools locally with VSCode for now.

[jgueytat]

Same behavior there : https://github.com/eclipse-cdt/cdt-gdb-vscode/issues/43

[GitMensch]

You you please re-run with showDevDebugOutput: true set for this extension and then post complete debug-log output?

[GitMensch]

I think this is related to the use of this.process.stdin.write within the sendRaw command; or actual, the use of sendRaw in the sendCommand function. @WebFreak001 is there a reason to not use sendCliCommand (so interpreter-exec internally) for nearly everything we currently use sendCommand for?

[WebFreak001]

hm the commands not starting with a - should be run through interpreter-exec because that makes it feel more like a GDB console, good for people who are used to it.

However I don't think that is related to this problem at all, that input afaik isn't being piped to the program directly usually. You can try launching the program in separate terminal mode, which makes it pop up a console window that does the std io handling.

[GitMensch]

However I don't think that is related to this problem at all, that input afaik isn't being piped to the program directly usually.

But the code suggest it does: We have internal use of sendCommand 20 times (7/8 times during startup [ssh/normal, both using a 5 commands init function, leaving 10 more invokes open afterwards]).

So the startup here takes 8 stdin.write during startup and potentially 10 others later (likely one before, too). If the application gets to the user input before those 8 commands are finished on the GDB side then we still have an "input" open in this case.

For me the main question is really: why use stdin.write at all?

[GitMensch]

Friendly ping @WebFreak001 because this really bugs me - as long as the program running is accepting input it should get through via stdin - and to allow that the extension should never send data there to communicate with GDB, shouldn't it?

[WebFreak001]

feel free to replace calls to sendRaw with sendCommand if they come from the extension and using -interpreter-exec

User input to the debug console should still support GDB commands if given as is and MI commands when starting with -

[jgueytat]

Hi guys,

I can get the getChar with the 25.1. The only thing is that I get a "Cancelled" in the Debug console at the end of the execution.

[jgueytat]

GitPod has still trouble with that.

[jgueytat]

Version : v25.1

With VSCode I can still miss the getChar() but it seems far much better.

[jgueytat]

With a recent GitPod Workspace : https://coral-puffin-q8gr472u.ws-eu17.gitpod.io

I miss the getChar and the breakpoint.

[jgueytat]

Here I got the getChar with the Hello lines at once.

[WebFreak001]

I don't think the fix for this has been released yet, but it should be there on master.

[jgueytat]

Thanks for the reply @WebFreak001! May be we could add on the main README.md the latest published versions on the markets.

[GitMensch]

That should be fixed now, no? An external console would obviously make that easier in any case, but that's a different issue.