[PATCH] Fix inferior deadlock with "target remote | CMD"

[John Baldwin]

On Monday, October 16, 2017 08:44:41 PM Pedro Alves wrote:
> Comparing test results between
> 
>   --target_board=native-gdbserver
>   --target_board=native-stdio-gdbserver
> 
> I noticed that gdb.base/bigcore.exp is failing with native-stdio-gdbserver:
> 
>   Running src/gdb/testsuite/gdb.base/bigcore.exp ...
>   FAIL: gdb.base/bigcore.exp: continue (timeout)
>   ...
> 
> The problem is that:
> 
>   1. When debugging with "target remote | CMD", the inferior's
>      stdout/stderr streams are connected to a pipe.
> 
>   2. The bigcore.c program prints a lot to the screen before it
>      reaches the breakpoint location that the "continue" shown above
>      wants to reach.
> 
>   3. GDB is not flushing the inferior's output pipe while the inferior
>      is running.
> 
>   4. The pipe becomes full.
> 
>   5. The inferior thus deadlocks.
> 
> The bug is #3 above, which is what this commit fixes.  A new test is
> added, that specifically exercises this scenario.  The test fails
> before the fix, and passes after, and gdb.base/bigcore.exp also starts
> passing.

Seems sensible.  It wasn't obvious to me from the code how stdout is
treated as compared to stderr, so I'm less confident on reviewing the
implementation.  One nit:

> @@ -589,6 +602,10 @@ ser_base_async (struct serial *scb,
>  	fprintf_unfiltered (gdb_stdlog, "[fd%d->asynchronous]\n",
>  			    scb->fd);
>        reschedule (scb);
> +
> +      if (scb->error_fd != -1)
> +	add_file_handler (scb->error_fd, handle_error_fd, scb);
> +
>      }

Extra blank line at the end?

> +
> +set expected_lines 3000

Pity this can't be a function of PIPE_BUF, but I suspect there's
no good way to do that.

-- 
John Baldwin