Re: Should this be on the blocker list for the 7.10 release?

[Pedro Alves <palves at redhat dot com>]

On 07/07/2015 07:35 PM, Simon Marchi wrote:
>> OK, the issue is that the new clone thread is found while inside
>> the linux_stop_and_wait_all_lwps call in this new bit of
>> code in linux-thread-db.c:
>>
>>       linux_stop_and_wait_all_lwps ();
>>
>>       ALL_LWPS (lp)
>> 	if (ptid_get_pid (lp->ptid) == pid)
>> 	  thread_from_lwp (lp->ptid);
>>
>>       linux_unstop_all_lwps ();
>>
>> We reach linux_handle_extended_wait with the "stopping"
>> parameter set to 1, and because of that we don't mark the
>> new lwp as resumed.  As consequence, the subsequent
>> resume_stopped_resumed_lwps (called first from that
>> linux_unstop_all_lwps) never resumes the new LWP...
>>
>> There's lots of cruft in linux_handle_extended_wait that no
>> longer makes sense.  This seems to fix your github test
>> for me, and causes no testsuite regressions.
> 
> It seems to fix most of it.  The only odd thing left that I
> noticed is that it leaves some of the inferiors there.  When I
> type "info inferiors" after running the program, I see one or
> two of them left.  I believe there should only be inferior #1
> left.

Hmm, indeed:

(gdb) info inferiors
  Num  Description       Executable
  4    process 8393      /home/pedro/bugs/src/test
  2    process 8388      /home/pedro/bugs/src/test
* 1    <null>            /home/pedro/bugs/src/test
(gdb) info threads

Calling prune_inferiors() at this point (from a top gdb)
does not remove them, because they still have inf->pid != 0.
Sounds like we miss mourning inferiors 2 and 4 somehow?

Thanks,
Pedro Alves