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: Sat, 14 Mar 2015 15:50:56 +0000
- 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>
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 <palves@redhat.com>
>>>
>>>> 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