Re: Inadvertently run inferior threads

> Date: Sat, 14 Mar 2015 15:50:56 +0000
> From: Pedro Alves <[email protected]>
> CC: [email protected]

Sorry for the long delay: this problem is rare, and it took me time to
find a semi-reliable reproducer for it, so I could investigate it
efficiently.

> I see what's going on here:
> 
>  #1 - we suppress the *stopped -> *running transitions/notification when
>    doing an inferior function call (the in_infcall checks in infrun.c).
> 
>  #2 - new threads are spawned and given *running state, because well,
>    they're running.
> 
>  #3 - we suppress the running -> *stopped transition when doing
>    an infcall, like in #1.  (The in_infcall check in normal_stop).
> 
>  #4 - result: _new_ threads end up in "running" state, even though they
>     are stopped.
> 
> I don't know off hand what the best fix is.
> 
> I think this bug must be in the tree for a while.  Curious that
> we don't have a test that exercises this...
> 
> I can't explain why you see _all_ threads as running instead of
> only the new ones, though.

I think I can explain that.

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.

What I don't understand is why doesn't the breakpoint we set at exit
from the inferior function countermand that.  I do see the effect of
that breakpoint if I turn on infrun debugging:

  infrun: target_wait (-1, status) =
  infrun:   4608 [Thread 4608.0x4900],
  infrun:   status->kind = stopped, signal = GDB_SIGNAL_TRAP
  infrun: TARGET_WAITKIND_STOPPED
  infrun: stop_pc = 0x88ba9f
  infrun: BPSTAT_WHAT_STOP_SILENT
  infrun: stop_waiting

Why don't we mark all threads as stopped when we hit the breakpoint?
is that because of #3 above?

Any ideas how to solve this annoying problem?

TIA