This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: Inadvertently run inferior threads
- From: Pedro Alves <palves at redhat dot com>
- To: Eli Zaretskii <eliz at gnu dot org>
- Cc: gdb at sourceware dot org
- Date: Mon, 15 Jun 2015 14:01:25 +0100
- Subject: Re: Inadvertently run inferior threads
- Authentication-results: sourceware.org; auth=none
- References: <83h9tq3zu3 dot fsf at gnu dot org> <55043A63 dot 6020103 at redhat dot com> <8361a339xd dot fsf at gnu dot org> <5504555C dot 804 at redhat dot com> <550458E0 dot 10206 at redhat dot com> <83y4jrsgui dot fsf at gnu dot org>
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