This is the mail archive of the
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: Wed, 10 Jun 2015 18:50:13 +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>
- Reply-to: Eli Zaretskii <eliz at gnu dot org>
> Date: Sat, 14 Mar 2015 15:50:56 +0000
> From: Pedro Alves <firstname.lastname@example.org>
> CC: email@example.com
Sorry for the long delay: this problem is rare, and it took me time to
find a semi-reliable reproducer for it, so I could investigate it
> 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.
I think I can explain that.
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:
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.
What I don't understand is why doesn't the breakpoint we set at exit
from the inferior function countermand that. I do see the effect of
that breakpoint if I turn on infrun debugging:
infrun: target_wait (-1, status) =
infrun: 4608 [Thread 4608.0x4900],
infrun: status->kind = stopped, signal = GDB_SIGNAL_TRAP
infrun: stop_pc = 0x88ba9f
Why don't we mark all threads as stopped when we hit the breakpoint?
is that because of #3 above?
Any ideas how to solve this annoying problem?