Re: GDB over TRAMP: problem with user I/O

[Vladilen Kozin <vladilen.kozin@gmail.com>]

Hi Michael,

thank you very much for digging into it. I played with ttys, too, and
had somewhat similar experience perhaps with less understanding on my
part. Similar bug plagues a ton of external debugging tools that
interface with GDB: google spits out a ton of complaints in code
blocks, netbeans, etc that's been popping up at least since 2009. All
suggested "solutions" amount to cargoculting some nonsense that on
occasion works.

There's one bug reported to GDB bugtracker ages ago that remains open
and might be of note:
https://sourceware.org/bugzilla/show_bug.cgi?id=11403

I've also updated to the latest version of everything just to confirm
the issue is present in the latest GDB - it is. I'll see if I really
want to dig deeper there. The only reason I went with this remote
debugging setup is cause OSX has become notoriously hostile to GDB, so
thought I might spin a Linux box with Vagrant and run all my probes
this way with Emacs acting a thin client. Would've been cool. Still,
Tramp is incredible piece of software - I'm in awe.

Will report back if discover smth noteworthy.

Best


On 10 December 2017 at 10:19, Michael Albinus <michael.albinus@gmx.de> wrote:
> Vladilen Kozin <vladilen.kozin@gmail.com> writes:
>
> Hi Vladilen,
>
>> Ran into problem with GDB over TRAMP. To me it looks like a bug in TRAMP
>> but could be that I've missed some settings required for such setup. Hence
>> posting here instead of bugs for now.
>
> First of all, I could reproduce it. But I'm not sure it is a Tramp
> error. Rather a missing feature.
>
> I've tried to understand how gdb is working. Took a while, I'm not
> familiar with that code. After gdb has been called, it starts to
> asynchronous processes: gud-<program> (bound to buffer *gud-<program>*),
> which is the gdb process itself, and gdb-inferior (bound to buffer
> *input/output of <program>*), which does not run any program, but
> allocates a tty only. You'll see this when calling "M-x list-processes".
>
> --8<---------------cut here---------------start------------->8---
> gdb-inferior    -2      run     *input/outpu... /dev/pts/4
> gud-debug       30367   run     *gud-debug*     /dev/pts/3   gdb -i=mi debug
> --8<---------------cut here---------------end--------------->8---
>
> Look at the local case: In the gdb-debug buffer, I've checked the used tty:
>
> --8<---------------cut here---------------start------------->8---
> (gdb) show inferior-tty
> Terminal for future runs of program being debugged is "/dev/pts/4".
> --8<---------------cut here---------------end--------------->8---
>
> Starting the test program, and checking outside Emacs for pts/4, you'll
> see that it is used by the gdb process:
>
> --8<---------------cut here---------------start------------->8---
> $ ps -eaf | grep pts/4
> albinus  30405 30367  0 11:07 pts/4    00:00:00 /home/albinus/tmp/fact/debug
> --8<---------------cut here---------------end--------------->8---
>
> Now I have performed the remote case. For simplicity, I have just
> prepended "/ssh::" to the test files, that's sufficient. The process
> list looks different:
>
> --8<---------------cut here---------------start------------->8---
> *tramp/ssh d... 30451   run     *tramp/ssh d... /dev/pts/3   /bin/sh -i
> gdb-inferior    30764   run     *input/outpu... /dev/pts/7   /bin/sh -i
> gud-debug       30740   run     *gud-debug*     /dev/pts/5   /bin/sh -i
> --8<---------------cut here---------------end--------------->8---
>
> You see, that the gdb-inferior does not return just a tty. This is not
> possible for remote processes. Instead, it is bound to /dev/pts/7, the
> tty of the running remote shell.
>
> In the gdb buffer, I've checked the used tty, again:
>
> --8<---------------cut here---------------start------------->8---
> (gdb) show inferior-tty
> Terminal for future runs of program being debugged is "/dev/pts/8".
> --8<---------------cut here---------------end--------------->8---
>
> Starting the test program, you'll see a different situation:
>
> --8<---------------cut here---------------start------------->8---
> $ ps -eaf | grep pts/8
> albinus  30567 30452  0 11:09 ?        00:00:00 sshd: albinus@pts/4,pts/6,pts/8
> albinus  30765 30567  0 11:09 pts/8    00:00:00 /bin/sh
> albinus  30927 26061  0 11:14 pts/9    00:00:00 grep pts/8
> $ ps -eaf | grep fact
> albinus  22347 22258  0 11:21 ?        00:00:00 /home/albinus/tmp/fact/debug
> albinus  22377 31587  0 11:22 pts/0    00:00:00 grep fact
> --8<---------------cut here---------------end--------------->8---
>
> The test program, debug, has no tty. And gdb tries to communicate with
> tty pts/8, which is the remote shell. Well, this cannot work. gdb tells
> you this with the message &"warning: GDB: Failed to set controlling
> terminal: Operation not permitted\n". Instead, your program is
> communicating with the shell which owns /dev/pts/8. You will see, that
> you could use the buffer *input/output of <program>* interactively.
>
> I have no idea how to fix this. Handling remote ttys simply does not
> work as gdb expects.
>
> Best regards, Michael.



-- 
Best regards
Vlad Kozin