This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: Inadvertently run inferior threads
- From: Eli Zaretskii <eliz at gnu dot org>
- To: Pedro Alves <palves at redhat dot com>
- Cc: gdb at sourceware dot org
- Date: Mon, 15 Jun 2015 22:06:46 +0300
- 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> <557ECCA5 dot 7050506 at redhat dot com> <83vbepngxm dot fsf at gnu dot org> <557EEF0E dot 1040400 at redhat dot com> <83ioaoopkh dot fsf at gnu dot org> <557F11CE dot 907 at redhat dot com>
- Reply-to: Eli Zaretskii <eliz at gnu dot org>
> Date: Mon, 15 Jun 2015 18:56:30 +0100
> From: Pedro Alves <palves@redhat.com>
> CC: gdb@sourceware.org
>
> On 06/15/2015 06:21 PM, Eli Zaretskii wrote:
> >> Date: Mon, 15 Jun 2015 16:28:14 +0100
> >> From: Pedro Alves <palves@redhat.com>
> >> CC: gdb@sourceware.org
> >>
> >>>> 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.
> >>>
> >>> Does that involve minus_one_ptid on GNU/Linux as well? If not, that
> >>> call will not mark all threads as running, will it?
> >>
> >> It does. user_visible_resume_ptid returns the same irrespective
> >> of target_can_async.
> >
> > Then how come your test program ended up showing just that additional
> > thread running? You even said you couldn't explain why I saw all my
> > threads running on Windows.
>
> Because linux-nat.c does not report any event to infrun when a
> thread is created, it just immediately goes back to waiting, unlike
> windows-nat.c, which reports TARGET_WAITKIND_SPURIOUS. By previous
> test program did not have the new thread trip on any event after
> its creation.
Then perhaps the right solution is not to call discard_cleanups at
that point under any condition, always call do_cleanups. After all,
all the threads are stopped at that point, so why not register that?