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: Tue, 23 Jun 2015 12:51:08 +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> <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>
On 06/15/2015 06:56 PM, Pedro Alves wrote:
> That's why I said:
> ~~~
> 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.
> ~~~
>
> And I just confirmed it, with a thread-specific breakpoint that
> trips on the wrong thread, thus, reporting a trap to the core,
> which does not cause a user-visible stop, and then ends up
> marking all threads running when we gdb internally re-resumes
> the program. Like so:
>
(...)
FYI, I've converted this to a proper testsuite test, and am
playing with potential fixes.
Thanks,
Pedro Alves