Bug 17347 - Regression: GDB stopped on run with attached process
Summary: Regression: GDB stopped on run with attached process
Status: RESOLVED FIXED
Alias: None
Product: gdb
Classification: Unclassified
Component: gdb (show other bugs)
Version: 7.8
: P2 normal
Target Milestone: 7.8
Assignee: Pedro Alves
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-09-03 07:43 UTC by Jan Kratochvil
Modified: 2014-10-22 18:33 UTC (History)
1 user (show)

See Also:
Host: x86_64-linux-gnu
Target: x86_64-linux-gnu
Build:
Last reconfirmed:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jan Kratochvil 2014-09-03 07:43:42 UTC
sleep 1h&p=$!;sleep 0.1;gdb -batch sleep $p -ex r

PASS:
[2] 22970
0x0000003fdf8bc780 in __nanosleep_nocancel () at ../sysdeps/unix/syscall-template.S:81
81      T_PSEUDO (SYSCALL_SYMBOL, SYSCALL_NAME, SYSCALL_NARGS)
/usr/bin/sleep: missing operand
Try '/usr/bin/sleep --help' for more information.
[Inferior 1 (process 23030) exited with code 01]
[2]+  Killed                  sleep 1h

FAIL:
[2]   Killed                  sleep 1h
[3]+  Stopped                 ./gdb/gdb -batch sleep $! -ex r

7180e04a36d812bbea2c280f2db33a7e8ce6b07b is the first bad commit
commit 7180e04a36d812bbea2c280f2db33a7e8ce6b07b
Author: Pedro Alves <palves@redhat.com>
Date:   Wed Jul 9 15:59:02 2014 +0100

    Fix "attach" command vs user input race

private Red Hat reference: https://bugzilla.redhat.com/show_bug.cgi?id=1136704
Comment 1 Pedro Alves 2014-09-03 09:58:30 UTC
The workaround is doing:

 gdb -ex "attach $PID" -ex "run"

instead of 

 gdb [-p] $PID -ex "run"

With the former, gdb waits for the attach command to complete before moving on to the "run" command, within execute_command.  But for the latter, attach_command is called directly from captured_main, and thus misses that waiting.  IOW, "run" is running before the attach had completed.  The broken terminal settings are just one symptom of that.
Comment 3 Sourceware Commits 2014-09-11 12:14:16 UTC
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "gdb and binutils".

The branch, master has been updated
       via  98880d46bdb1e88db447f876a8ac1f2a4de97dae (commit)
       via  4c92ff2c35392b68ee9172af979483b32aaa3d7b (commit)
      from  bd9269f70c70b1218b0eb73a6f487d6ca481e5ac (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -----------------------------------------------------------------
https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=98880d46bdb1e88db447f876a8ac1f2a4de97dae

commit 98880d46bdb1e88db447f876a8ac1f2a4de97dae
Author: Pedro Alves <palves@redhat.com>
Date:   Thu Sep 11 13:04:15 2014 +0100

    gdb/17347 - Regression: GDB stopped on run with attached process
    
    Doing:
    
      gdb --pid=PID -ex run
    
    Results in GDB getting a SIGTTIN, and thus ending stopped.  That's
    usually indicative of a missing target_terminal_ours call.
    
    E.g., from the PR:
    
     $ sleep 1h & p=$!; sleep 0.1; gdb -batch sleep $p -ex run
     [1] 28263
     [1]   Killed                  sleep 1h
    
     [2]+  Stopped                 gdb -batch sleep $p -ex run
    
    The workaround is doing:
    
     gdb -ex "attach $PID" -ex "run"
    
    instead of
    
     gdb [-p] $PID -ex "run"
    
    With the former, gdb waits for the attach command to complete before
    moving on to the "run" command, because the interpreter is in sync
    mode at this point, within execute_command.  But for the latter,
    attach_command is called directly from captured_main, and thus misses
    that waiting.  IOW, "run" is running before the attach continuation
    has run, before the program stops and attach completes.  The broken
    terminal settings are just one symptom of that.  Any command that
    queries or requires input results in the same.
    
    The fix is to wait in catch_command_errors (which is specific to
    main.c nowadays), just like we wait in execute_command.
    
    gdb/ChangeLog:
    2014-09-11  Pedro Alves  <palves@redhat.com>
    
    	PR gdb/17347
    	* main.c: Include "infrun.h".
    	(catch_command_errors, catch_command_errors_const): Wait for the
    	foreground command to complete.
    	* top.c (maybe_wait_sync_command_done): New function, factored out
    	from ...
    	(maybe_wait_sync_command_done): ... here.
    	* top.h (maybe_wait_sync_command_done): New declaration.
    
    gdb/testsuite/ChangeLog:
    2014-09-11  Pedro Alves  <palves@redhat.com>
    
    	PR gdb/17347
    	* lib/gdb.exp (gdb_spawn_with_cmdline_opts): New procedure.
    	* gdb.base/attach.exp (test_command_line_attach_run): New
    	procedure.
    	(top level): Call it.

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=4c92ff2c35392b68ee9172af979483b32aaa3d7b

commit 4c92ff2c35392b68ee9172af979483b32aaa3d7b
Author: Pedro Alves <palves@redhat.com>
Date:   Thu Sep 11 13:04:14 2014 +0100

    testsuite: refactor spawn and wait for attach
    
    Several places in the testsuite have a copy of a snippet of code that
    spawns a test program, waits a bit, and then does some PID munging for
    Cygwin.  This is in order to have GDB attach to the spawned program.
    
    This refactors all that to a common procedure.
    
    (multi-attach.exp wants to spawn multiple processes, so this makes the
    new procedure's interface work with lists.)
    
    Tested on x86_64 Fedora 20.
    
    gdb/testsuite/ChangeLog:
    2014-09-11  Pedro Alves  <palves@redhat.com>
    
    	* lib/gdb.exp (spawn_wait_for_attach): New procedure.
    	* gdb.base/attach.exp (do_attach_tests, do_call_attach_tests)
    	(do_command_attach_tests): Use spawn_wait_for_attach.
    	* gdb.base/solib-overlap.exp: Likewise.
    	* gdb.multi/multi-attach.exp: Likewise.
    	* gdb.python/py-prompt.exp: Likewise.
    	* gdb.python/py-sync-interp.exp: Likewise.
    	* gdb.server/ext-attach.exp: Likewise.

-----------------------------------------------------------------------

Summary of changes:
 gdb/ChangeLog                               |   11 ++++
 gdb/main.c                                  |    9 +++
 gdb/testsuite/ChangeLog                     |   19 ++++++
 gdb/testsuite/gdb.base/attach.exp           |   86 +++++++++++++++------------
 gdb/testsuite/gdb.base/solib-overlap.exp    |   11 +---
 gdb/testsuite/gdb.multi/multi-attach.exp    |   13 +---
 gdb/testsuite/gdb.python/py-prompt.exp      |   10 +---
 gdb/testsuite/gdb.python/py-sync-interp.exp |   10 +---
 gdb/testsuite/gdb.server/ext-attach.exp     |   10 +---
 gdb/testsuite/lib/gdb.exp                   |   41 +++++++++++++
 gdb/top.c                                   |   28 ++++++---
 gdb/top.h                                   |    8 +++
 12 files changed, 163 insertions(+), 93 deletions(-)
Comment 4 Sourceware Commits 2014-09-11 12:18:34 UTC
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "gdb and binutils".

The branch, gdb-7.8-branch has been updated
       via  528c4509aeb4f92174344903dd25ebee222ce0fa (commit)
       via  7ec5670becb3f978f4d2f4df252ad0cbf805e37a (commit)
      from  f5905305bcb38a17863982f336da6a91990165c7 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -----------------------------------------------------------------
https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=528c4509aeb4f92174344903dd25ebee222ce0fa

commit 528c4509aeb4f92174344903dd25ebee222ce0fa
Author: Pedro Alves <palves@redhat.com>
Date:   Thu Sep 11 13:04:15 2014 +0100

    gdb/17347 - Regression: GDB stopped on run with attached process
    
    Doing:
    
      gdb --pid=PID -ex run
    
    Results in GDB getting a SIGTTIN, and thus ending stopped.  That's
    usually indicative of a missing target_terminal_ours call.
    
    E.g., from the PR:
    
     $ sleep 1h & p=$!; sleep 0.1; gdb -batch sleep $p -ex run
     [1] 28263
     [1]   Killed                  sleep 1h
    
     [2]+  Stopped                 gdb -batch sleep $p -ex run
    
    The workaround is doing:
    
     gdb -ex "attach $PID" -ex "run"
    
    instead of
    
     gdb [-p] $PID -ex "run"
    
    With the former, gdb waits for the attach command to complete before
    moving on to the "run" command, because the interpreter is in sync
    mode at this point, within execute_command.  But for the latter,
    attach_command is called directly from captured_main, and thus misses
    that waiting.  IOW, "run" is running before the attach continuation
    has run, before the program stops and attach completes.  The broken
    terminal settings are just one symptom of that.  Any command that
    queries or requires input results in the same.
    
    The fix is to wait in catch_command_errors (which is specific to
    main.c nowadays), just like we wait in execute_command.
    
    gdb/ChangeLog:
    2014-09-11  Pedro Alves  <palves@redhat.com>
    
    	PR gdb/17347
    	* main.c: Include "infrun.h".
    	(catch_command_errors, catch_command_errors_const): Wait for the
    	foreground command to complete.
    	* top.c (maybe_wait_sync_command_done): New function, factored out
    	from ...
    	(maybe_wait_sync_command_done): ... here.
    	* top.h (maybe_wait_sync_command_done): New declaration.
    
    gdb/testsuite/ChangeLog:
    2014-09-11  Pedro Alves  <palves@redhat.com>
    
    	PR gdb/17347
    	* lib/gdb.exp (gdb_spawn_with_cmdline_opts): New procedure.
    	* gdb.base/attach.exp (test_command_line_attach_run): New
    	procedure.
    	(top level): Call it.

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=7ec5670becb3f978f4d2f4df252ad0cbf805e37a

commit 7ec5670becb3f978f4d2f4df252ad0cbf805e37a
Author: Pedro Alves <palves@redhat.com>
Date:   Thu Sep 11 13:14:47 2014 +0100

    testsuite: refactor spawn and wait for attach
    
    Several places in the testsuite have a copy of a snippet of code that
    spawns a test program, waits a bit, and then does some PID munging for
    Cygwin.  This is in order to have GDB attach to the spawned program.
    
    This refactors all that to a common procedure.
    
    (multi-attach.exp wants to spawn multiple processes, so this makes the
    new procedure's interface work with lists.)
    
    Tested on x86_64 Fedora 20.
    
    gdb/testsuite/ChangeLog:
    2014-09-11  Pedro Alves  <palves@redhat.com>
    
    	* lib/gdb.exp (spawn_wait_for_attach): New procedure.
    	* gdb.base/attach.exp (do_attach_tests, do_call_attach_tests)
    	(do_command_attach_tests): Use spawn_wait_for_attach.
    	* gdb.base/solib-overlap.exp: Likewise.
    	* gdb.multi/multi-attach.exp: Likewise.
    	* gdb.python/py-prompt.exp: Likewise.
    	* gdb.python/py-sync-interp.exp: Likewise.
    	* gdb.server/ext-attach.exp: Likewise.

-----------------------------------------------------------------------

Summary of changes:
 gdb/ChangeLog                               |   11 ++++
 gdb/main.c                                  |    9 +++
 gdb/testsuite/ChangeLog                     |   19 ++++++
 gdb/testsuite/gdb.base/attach.exp           |   86 +++++++++++++++------------
 gdb/testsuite/gdb.base/solib-overlap.exp    |   11 +---
 gdb/testsuite/gdb.multi/multi-attach.exp    |   13 +---
 gdb/testsuite/gdb.python/py-prompt.exp      |   10 +---
 gdb/testsuite/gdb.python/py-sync-interp.exp |   10 +---
 gdb/testsuite/gdb.server/ext-attach.exp     |   10 +---
 gdb/testsuite/lib/gdb.exp                   |   41 +++++++++++++
 gdb/top.c                                   |   28 ++++++---
 gdb/top.h                                   |    8 +++
 12 files changed, 163 insertions(+), 93 deletions(-)
Comment 5 Pedro Alves 2014-09-11 12:38:29 UTC
Fixed.