Cannot read from stdin (with openGdbConsole on)

[a1994846931931]

I attempted to debug a program through a gdb console (set openGdbConsole to true) so that the program could read from stdin. But there's an error as shown below:

I'm just wondering if it is a bug of cdt-gdb-adapter, or am I just making a mistake? I tried to make things right, but only to find out that it's really hard to fix. Could anyone give me some advice?

Thank you very much!

[jonahgraham]

I think in this case you have suspended in the middle of read.c, but you don't have read.c on your computer (at least not where GDB can find it). So the debug adapter is reporting back the current stopped location as .../read.c and VS Code is trying to open that file. It is VS Code that is giving that error. If you install (or have) the source for glibc then you can use set substitute-path to map these together.

The debug adapter could (should) be made to fail more graciously in this case and suggest some solutions - such as mapping source locations, or offering to fall back on disassembly or ???

[a1994846931931]

@jonahgraham
Thanks for your reply!
I am new to gdb, so I need to study more to understand your comment here. But I was suspicious when I read but you don't have read.c on your computer (at least not where GDB can find it), because I managed to debug the program with CLI gdb. Here is how I made it:

1. Exec gdb build/main;
2. exec run;
3. since there's no breakpoint, the program stopped in the line waiting for input;
4. input a char, and the program continues.

So IMHO, it seems that gdb is able to locate read.c on my computer, right? A gif is posted below in case my explanation is not clear enough:

What's your opinion on this? Do you have any further advice?

[jonahgraham]

In your original post your gdb stopped because of a signal. Where it stopped was in read.c. You have highlighted an interesting question that I hope @marechal-p can comment on, why did vscode's terminal send a SIGTTIN in the integrated case but not when running gdb on its own?

[jonahgraham]

PS I have not tried to replicate. I'll try to tomorrow - it's getting late here.

[a1994846931931]

@jonahgraham Thanks for your comment.

And there's another information you might find useful: I could reproduce it in theia.

[a1994846931931]

@marechal-p Hi, Paul, do you have any clue for fixing this problem? Thank you very much!

[paul-marechal]

I was trying to read about ttys and this SIGTTIN, apparently this is dispatched to processes running in background process groups when they try to interact with the master tty. Is it related to the way we create a new tty and hook GDB onto it? I am a bit short of ideas at the moment...

[jonahgraham]

Hi @marechal-p - thanks for the insights. I think that @a1994846931931 is running into problems no one else has much because most everyone else is doing embedded which doesn't have an inferior in the same way.

[a1994846931931]

@jonahgraham @marechal-p I was able to get rid of the SIGTTIN error by executing gdb command handle SIGTTIN nostop noprint ( pass '-ex', 'handle SIGTTIN nostop noprint' arguments to gdb ). But the problem remains that I cannot redirect my input to the slave tty. The input was regarded as gdb command:

Do you have any suggestions on this?

[jonahgraham]

This is the same issue (but other end of the stream) as #161. Closing this in favour of #161.