On OpenSolaris b111, gdb 7.0.1 and 7.0
I try to debug a program with different tty:
gdb -tty /dev/pts/6 a.out
when I start the program I get:
warning: GDB: Failed to set controlling terminal: Inappropriate ioctl for device
in the output.
With gdb 6.8 and prior I have not seen this.
This issue started with:
[RFA] Fix GDB's handling of the inferior controlling terminal.
(as reported by Alan Matsuoka)
The changed fixed other problems described there.
Either you should ignore the warning as it has the same functionality as gdb-6.x
before the change above. For example signals do not work in that TTY, though.
If you want to benefit from the fully dedicated TTY to the inferior process you
should run first the helper pasted below.
(One can discuss whether to call TIOCSCTTY with 0 (current) or 1. IMO the
current value is right, 1 would not make it much easier and it would just
require root privileges plus make it whole less clear.)
I would suggest for GDB to make some notice to such a helper in the warning.
Thanks for the bugreport, is it OK this way?
/* tty;exec disowntty */
end (const char *msg)
void (*orig) (int signo);
setbuf (stdout, NULL);
orig = signal (SIGHUP, SIG_IGN);
if (orig != SIG_DFL)
end ("signal (SIGHUP)");
/* Verify we are the sole owner of the tty. */
if (ioctl (STDIN_FILENO, TIOCSCTTY, 0) != 0)
/* Disown the tty. */
if (ioctl (STDIN_FILENO, TIOCNOTTY) != 0)
end ("OK, disowned");
Hi Egor and Jan, what is the status of this bug?
This is still valid at least on Solaris 11.2 and MacOS X 10.10 with GDB 7.7
Input is not redirected to a process being debugged but output from a process appears in a terminal specified
Looks like the same issue plagues GDB 7.11.1.
Reported on emacs mailing list https://lists.gnu.org/archive/html/help-gnu-emacs/2017-12/msg00114.html since I thought the issue might be with Tramp. This was reported for older Linux box with GDB 7.7, but I later reproduced on Ubuntu 16.04.3 LTS (GNU/Linux 4.4.0-104-generic x86_64) and GDB 7.11.1
When debugging on local machine this is usually benign, but it does appear to break attempt to debug with I/O when debugging remotely say over TRAMP. See the mailing list post above for details.