As pointed out by Domq half a year ago, it seems like the gdb doesn’t have to call another wait4(). The patch can fix the deadlock problem. I am having limited time dig deeper into the root cause of the bug, but I will try poking around and see what I can find out.


Best,
Louis

> On Feb 2, 2022, at 4:26 PM, Simon Marchi <simark@simark.ca> wrote:
> 
> On 2022-02-02 4:01 p.m., Siwei He via Gdb-patches wrote:
>> Hi Simon,
>> 
>> You are absolutely right. I am new to the community and I noticed that I
>> didn't merge two of my commits together in the patch file. I have already
>> merged them and included in the attachment in this email. I also uploaded
>> it to the bug report:
>> https://sourceware.org/bugzilla/attachment.cgi?id=13953
>> 
>> Best,
>> Louis
> Thanks, that makes more sense.
> 
> I'd like if we could at least get some understanding of what's happening
> here and get an explanation in the commit message, otherwise it feels
> like just feels like throwing random things on the wall and seeing what
> sticks.
> 
> Could you please provide the output of a GDB session running a trivial
> program, with both "set debug infrun 1" and "set debug darwin 12" (not a
> typo, the last one is really "12")?  Then we can have an idea of the
> sequence of events.  If you can get one where things work and one where
> things don't work, it would be even better, since it would allow us to
> compare.
> 
> I'm trying to understand what the code you change does.  It is in a
> scope that starts like this:
> 
>  else if (hdr->msgh_id == 0x48)
>    {
>      /* MACH_NOTIFY_DEAD_NAME: notification for exit.  */
> 
> What does that mean, does it mean we have received some message /
> notification to tell us the inferior has exited?  So what does it mean
> to then receive a WIFSTOPPED wait status for that pid?
> 
> I think it would be useful do add a debug print just after the wait4
> call above, to print (in hexadecimal) the wstatus value returned by
> wait4.
> 
> Simon