Re：Re：GDB often is blocked at async_file_flush

["周春明(日月)" <riyue.zcm@alibaba-inc.com>]

------------------------------------------------------------------
发件人：Simon Marchi <simon.marchi@polymtl.ca>
发送时间：2021年7月5日(星期一) 08:53
收件人：周春明(日月) <riyue.zcm@alibaba-inc.com>; Gdb-patches <gdb-patches-bounces+riyue.zcm=alibaba-inc.com@sourceware.org>; gdb-patches <gdb-patches@sourceware.org>
主　题：Re: Re：GDB often is blocked at async_file_flush

On 2021-07-04 8:13 p.m., 周春明(日月) wrote:
> Hi Simon,
> Thanks for reply.
> and yes, gdb is stuck in this loop:
>   do
>     {
>       ret = read (linux_nat_event_pipe[0], &buf, 1);
>     }
>   while (ret >= 0 || (ret == -1 && errno == EINTR));
> 
> The ret from read is always 0 when stuck happens. With my further debug in kernel pipe_read, this situation happens when pipe->writers is NULL.
> Because this is random issue, I compared with normal execution, the pipe->writers is not NULL and pipe->wait_writers is null, pipe_read will return -EAGAIN, then above loop exit normally.
> So do you know when pipe->writers would be NULL? sub-process is suspended?

Hmm, does that mean that the writer end of the pipe would be closed, but
not the read end?  I don't see how that can happen, as they are both
closed as a pair in linux_async_pipe, when enable is 0.

I tried the following test program, and indeed read returns 0:

    #include <unistd.h>
    #include <stdio.h>
    #include <fcntl.h>

    int main ()
    {
      int fds[2];
      pipe(fds);
      fcntl(fds[0], F_SETFL, O_NONBLOCK);
      fcntl(fds[1], F_SETFL, O_NONBLOCK);
      close(fds[1]);

      char c;
      int ret = read (fds[0], &c, 1);
      if (ret < 0)
 perror("read");

      printf("ret = %d\n", ret);
    }

When you have that infinite loop, what is the value of the two elements
of linux_nat_event_pipe?
[David] I tried this, when infinit loop happens, two elements of linux_nat_event_pipe are "
*****pipe[1]:12, pipe[0]:11",  do you know any other case will result in pipe[0]-read returns 0 except closing pipe[1]?
If you could share a reproducer for how to get to this state, it would
be useful.
[David] The project is our custom project for our asic, which isn't public yet. I also tried narrow down special case to reproduce it in common GDB, but failed.

-David 

Simon