[Bug tui/21817] New: gdb session suspended when run in background

[jim at realintent dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=21817

Bug ID: 21817
Summary: gdb session suspended when run in background
Product: gdb
Version: 7.12.1
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: tui
Assignee: unassigned at sourceware dot org
Reporter: jim at realintent dot com
Target Milestone: ---

Help!
I'm running gdb 7.12.1 under CentOS 6.8.

My application has a signal handler that invokes gdb in batch when a SEGV or
other bad signals occur. It invokes gdb with the application's process ID as
gdb --pid=<pid> --nx -x cmd.gdb --batch
This had worked fine under RH-5 and older versions of gdb.
With gdb 7.12.1, the gdb process is immediately suspended before any commands
are run.

I debugged the suspended gdb process, which shows that gdb was stopped in
set_tty_state(). This ought not to have happened, as gdb was run as a
background process and should not have tried to configure the terminal.
The output of 'where' and 'backtrace full' are below.

Is there a workaround for this problem?

(gdb) where
#0 0x0000003a78ee0048 in tcsetattr () from /lib64/libc.so.6
#1 0x00000000004491e1 in set_tty_state (scb=<optimized out>, state=<optimized
out>) at ser-unix.c:152
#2 hardwire_set_tty_state (scb=<optimized out>, ttystate=<optimized out>) at
ser-unix.c:209
#3 0x0000000000660d4b in child_terminal_inferior (self=<optimized out>) at
inflow.c:276
#4 0x000000000044e5b9 in linux_nat_terminal_inferior (self=<optimized out>) at
linux-nat.c:4462
#5 0x0000000000587f09 in target_terminal_inferior () at target.c:501
#6 0x000000000053a8aa in attach_command (args=0x26bbf70 "11882",
***@entry=0x7ffce9adc284 "11882", from_tty=***@entry=0) at infcmd.c:2863
#7 0x00000000005575b8 in catch_command_errors (command=0x53a810
<attach_command(char*, int)>, arg=***@entry=0x7ffce9adc284 "11882", from_tty=0)
at main.c:375
#8 0x000000000055818b in captured_main (data=0x7ffce9ad9db0) at main.c:1065
#9 gdb_main (args=***@entry=0x7ffce9ad9ed0) at main.c:1159
#10 0x0000000000409595 in main (argc=<optimized out>, argv=<optimized out>) at
gdb.c:32

(gdb) backtrace full
#0 0x0000003a78ee0048 in tcsetattr () from /lib64/libc.so.6
No symbol table info available.
#1 0x00000000004491e1 in set_tty_state (scb=<optimized out>, state=<optimized
out>) at ser-unix.c:152
No locals.
#2 hardwire_set_tty_state (scb=<optimized out>, ttystate=<optimized out>) at
ser-unix.c:209
state = <optimized out>
#3 0x0000000000660d4b in child_terminal_inferior (self=<optimized out>) at
inflow.c:276
result = <optimized out>
inf = 0x27b2f20
tinfo = 0x27b7cd0
#4 0x000000000044e5b9 in linux_nat_terminal_inferior (self=<optimized out>) at
linux-nat.c:4462
No locals.
#5 0x0000000000587f09 in target_terminal_inferior () at target.c:501
ui = <optimized out>
#6 0x000000000053a8aa in attach_command (args=0x26bbf70 "11882",
***@entry=0x7ffce9adc284 "11882", from_tty=***@entry=0) at infcmd.c:2863
async_exec = 0
attach_target = 0x0
inferior = 0x27b2f20
args_chain = 0x7a87e0 <sentinel_cleanup>
mode = <optimized out>
#7 0x00000000005575b8 in catch_command_errors (command=0x53a810
<attach_command(char*, int)>, arg=***@entry=0x7ffce9adc284 "11882", from_tty=0)
at main.c:375
was_sync = 0
exception_try_scope_instance = {saved_state = 0x26bc070}
#8 0x000000000055818b in captured_main (data=0x7ffce9ad9db0) at main.c:1065
execarg = <optimized out>
cdarg = 0x0
save_auto_load = 1
argc = <optimized out>
ttyarg = 0x0
cmdarg_vec = 0x26bc790
system_gdbinit = 0x0
inhibit_home_gdbinit = 0
print_help = 0
context = 0x7ffce9ad9db0
argv = <optimized out>
local_gdbinit = 0x0
i = <optimized out>
objfile = <optimized out>
pre_stat_chain = 0x7a87e0 <sentinel_cleanup>
pid_or_core_arg = 0x0
cmdarg_p = 0x0
home_gdbinit = 0x27b7d10 "/home/jim/.gdbinit"
print_version = 0
corearg = 0x0
set_args = 0
symarg = <optimized out>
pidarg = 0x7ffce9adc284 "11882"
dirarg = 0x26bbf70
dirsize = 1
ndir = <optimized out>
quiet = 1
print_configuration = 0
#9 gdb_main (args=***@entry=0x7ffce9ad9ed0) at main.c:1159
exception_try_scope_instance = {saved_state = 0x7a87e0
<sentinel_cleanup>}
#10 0x0000000000409595 in main (argc=<optimized out>, argv=<optimized out>) at
gdb.c:32
args = {argc = 6, argv = 0x7ffce9ad9fd8, interpreter_p = 0x755884
"console"}

[jim at realintent dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=21817

--- Comment #1 from Jim Foley <jim at realintent dot com> ---

I should add that the gdb process is suspended when the application is
run in background. If the application (and gdb itself) is run in foreground,
then it runs correctly.

[jim at realintent dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=21817

--- Comment #2 from Jim Foley <jim at realintent dot com> ---

More about this:
I've fixed this in a customized gdb build with this change in inflow.c:

----
static int
gdb_has_a_terminal (void)
{
// return initial_gdb_ttystate != NULL;
return (initial_gdb_ttystate != NULL) && (batch_flag == 0);
}
----

This fix works successfully for our purposes.

I've tried to create a reproducible testcase on a 'hello world' style binary
but
didn't succeed. It must be that something in my application contributes
to the reason gdb hangs.

[tromey at sourceware dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=21817

Tom Tromey <tromey at sourceware dot org> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |tromey at sourceware dot org
Component|tui |gdb

--- Comment #3 from Tom Tromey <tromey at sourceware dot org> ---
I think this isn't a TUI bug, so I'm moving it.
I wonder if this has been fixed since then.