1. Time and date of problem: Always. 2. System architecture(s): [ernesto@cdlx01 gdb]$ more /etc/redhat-release Red Hat Enterprise Linux Client release 5.5 (Tikanga) [ernesto@cdlx01 gdb]$ gdb -v GNU gdb (GDB) Red Hat Enterprise Linux (7.0.1-23.el5) Copyright (C) 2009 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "i386-redhat-linux-gnu". For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>. [ernesto@cdlx01 gdb]$ uname -a Linux cdlx01 2.6.18-194.el5 #1 SMP Tue Mar 16 21:52:43 EDT 2010 i686 i686 i386 GNU/Linux 3. Provide a clear and concise problem description as it is understood at the time of escalation. Please be as specific as possible in your description. Do not use the generic term "hang", as that can mean many things. Unable to debug: ====== [ernesto@cdlx01 linux-x86]$ gdb gdbTest -tty /dev/pts/10 GNU gdb (GDB) Red Hat Enterprise Linux (7.0.1-23.el5) Copyright (C) 2009 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "i386-redhat-linux-gnu". For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>... Reading symbols from /usr/local/lcls/epics/iocTop/test/bin/linux-x86/gdbTest...done. (gdb) b main Breakpoint 1 at 0x804a5fc: file ../gdbTestMain.cpp, line 16. (gdb) r Starting program: /usr/local/lcls/epics/iocTop/test/bin/linux-x86/gdbTest warning: .dynamic section for "/lib/libc.so.6" is not at the expected address warning: difference appears to be caused by prelink, adjusting expectations [Thread debugging using libthread_db enabled] Breakpoint 1, main (argc=1, argv=0xbfffe114) at ../gdbTestMain.cpp:16 16 if(argc>=2) { (gdb) And now my other terminal says: [ernesto@cdlx01 ~]$ warning: GDB: Failed to set controlling terminal: Operation not permitted ====== *Reproduce as follows : On RHEL 5.5 create the following file tester.c : #include <stdio.h> int main () { printf("hello world"); } compile file : # gcc -ggdb -o tester tester.c Start terminals until you have pts10 run GDB # gdb tester -tty /dev/pts/10 at the gdb prompt set a breakpoint : (gdb) b main then run the code : (gdb) r This will then display the following message on the pts/10 terminal : warning: GDB: Failed to set controlling terminal: Operation not permitted warning: GDB: Failed to set controlling terminal: Operation not permitted 4. Specific action requested of SEG: Not sure this is a bug or not, but the customer said it is working on RHEL5U4 5. Is a defect (bug) in the product suspected? yes/no No 6. Does a proposed patch exist? yes/no No 7. What is the impact to the customer when they experience this problem? I think workaround it using GDB on RHEL5U4. That's because it's a much older version of gdb. http://sourceware.org/ml/gdb-patches/2008-03/msg00103.html is the patch that eventually went into gdb-7.0.1-23.el5. that seems to be the source of the problem. seems to have been reported before http://sourceware.org/bugzilla/show_bug.cgi?id=11403
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 in that TTY the helper pasted below. You have to close the TTY afterwards. (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 */ #include <sys/ioctl.h> #include <unistd.h> #include <stdio.h> #include <limits.h> #include <stdlib.h> #include <signal.h> static void end (const char *msg) { perror (msg); for (;;) pause (); } int main (void) { 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) end ("TIOCSCTTY"); /* Disown the tty. */ if (ioctl (STDIN_FILENO, TIOCNOTTY) != 0) end ("TIOCNOTTY"); end ("OK, disowned"); return 1; }
It is not fixable in GDB. I can only disable a warning message to strictly match the previous GDB behavior. For some forced takover of a console please consult kernel tty people.
Just tried disowntty at Linux 5.7.2 and it works fine. However, ^C in the xterm running it is not delivered. Perhaps this was always the case; pkill disowntty from another xterm works instead.
FWIW, gdb's set inferior-tty command (same as gdb -tty) works fine under Cygwin. In the target mintty or xterm, issue 'tty; sleep 1000000'. gdb -tty will take the controlling terminal (output by 'tty') off sleep.exe and give it to the program being debugged. Afterwards, as with disowntty above, you need to 'pkill sleep' to get the terminal back (but you do get to keep the terminal :)