Re: Re：Re：GDB often is blocked at async_file_flush

[Pedro Alves <pedro@palves.net>]

On 2021-07-05 1:25 p.m., 周春明(日月) via Gdb-patches wrote:
> Hi Simon,
> I did more experiments today, basically I can confirm the reason of GDB stuck in that loop is the linux_nat_event_pipe[1] is closed while SIGCHLD happens.
> They are asynchronize, so the issue is random.
> But I still don't know exactly why linux_nat_event_pipe[1] is closed with unexpected.  Even sometimes SIGCHLD happens at same time as below line52: target_async(0);
> 
> 36| void
> 37| inferior_event_handler (enum inferior_event_type event_type)
> 38| {
> 39|  switch (event_type)
> 40|  {
> 41|  case INF_REG_EVENT:
> 42|  fetch_inferior_event ();
> 43|  break;
> 44|
> 45|  case INF_EXEC_COMPLETE:
> 46|  if (!non_stop) 
> 47|  {
> 48|  /* Unregister the inferior from the event loop. This is done
> 49|   so that when the inferior is not running we don't get
> 50|   distracted by spurious inferior output. */
> 51|  if (target_has_execution && target_can_async_p ())
> 52+> target_async (0);
> 53|  }

Note that linux_async_pipe closes the pipe with SIGCHLD blocked.  See
block_child_signals call.

I think you mentioned you're targeting some private architecture?
Could there be some bug at the libc or kernel level with blocking signals?
This is a glibc-based system?

Or maybe there's some stray code elsewhere in your GDB that closes
the wrong file descriptor?

I would maybe debug gdb and put a conditional breakpoint at "close" (conditional
on the file descriptor number), trying to catch where the pipe is closed.