This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH] Fix inferior deadlock with "target remote | CMD"
- From: John Baldwin <jhb at freebsd dot org>
- To: gdb-patches at sourceware dot org
- Cc: Pedro Alves <palves at redhat dot com>
- Date: Wed, 18 Oct 2017 10:38:03 -0700
- Subject: Re: [PATCH] Fix inferior deadlock with "target remote | CMD"
- Authentication-results: sourceware.org; auth=none
- References: <1508183081-22424-1-git-send-email-palves@redhat.com>
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