Re: Inadvertently run inferior threads

[Pedro Alves <palves at redhat dot com>]

On 06/10/2015 04:50 PM, Eli Zaretskii wrote:

>> I can't explain why you see _all_ threads as running instead of
>> only the new ones, though.
> 
> I think I can explain that.

Thanks for the investigation.

> 
> First, in MinGW native debugging the function set_running, as well as
> most other thread-related functions that change state, are always
> called with minus_one_ptid as their ptid argument, and therefore they
> change the state of all the threads.
> 
> The second part of the puzzle is that when these threads are started,
> we are inside the 'proceed' call made by 'run_inferior_call'.  When a
> thread like this is started during this time, we get
> TARGET_WAITKIND_SPURIOUS event inside 'handle_inferior_event', and
> call 'resume'.  But when 'resume' is called like that, inferior_ptid
> is set to the thread ID of the new thread that was started, and which
> triggered TARGET_WAITKIND_SPURIOUS.  So when 'resume' wants to
> suppress the stopped -> running transition, here:
> 
> 	  if (!tp->control.in_infcall)
> 	    set_running (user_visible_resume_ptid (user_step), 1);
> 
> it winds up calling 'set_running', because the in_infcall flag is set
> on the thread that called the inferior function, not on the thread
> which was started and triggered TARGET_WAITKIND_SPURIOUS.
> 
> So 'set_running' is called, and it is called with minus_one_ptid,
> which then has the effect of marking all the threads as running.

So that should mean that even for GNU/Linux, it should be possible
to end in the exact same, when any thread other than the one that we
had started the infcall in reports an event that doesn't cause a stop.
E.g., a thread specific breakpoint, a "handle nostop" signal, etc.

Thanks,
Pedro Alves