Re: Inadvertently run inferior threads

On 03/14/2015 03:35 PM, Pedro Alves wrote:
> On 03/14/2015 02:55 PM, Eli Zaretskii wrote:
>>> Date: Sat, 14 Mar 2015 13:40:51 +0000
>>> From: Pedro Alves <[email protected]>
>>>
>>>> Once this happens, the debugging session seems to be ruined: the only
>>>> thing I can do is kill the inferior and quit the debugger.  Because
>>>> there doesn't seem to be any way of stopping the threads again, not on
>>>> Windows anyway.
>>>
>>> The threads are probably stopped, and GDB managed to get out of
>>> sync somehow.
>>
>> In that case, the cause of it getting out of sync is the new thread
>> that was started (probably by Windows)?
> 
> Calling a function that ends up starting new threads should
> work OK, but indeed that seems to be broken...
> 
> On GNU/Linux, and a trivial program with:
> 
> ~~~
> void
> start_thread (void)
> {
>   pthread_t thread;
> 
>   pthread_create (&thread, NULL, thread_function, NULL);
> }
> ~~~
> 
> results in:
> 
> (gdb) p start_thread ()
> [New Thread 0x7ffff7fc1700 (LWP 9903)]
> $1 = void
> (gdb) info threads
>   Id   Target Id         Frame
>   2    Thread 0x7ffff7fc1700 (LWP 9903) "start-thread-in" (running)
> * 1    Thread 0x7ffff7fc2740 (LWP 9899) "start-thread-in" main () at start-thread-infcall.c:35
> 

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.

Thanks,
Pedro Alves