From: Don Breazeal <donb@codesourcery.com>
To: <gdb-patches@sourceware.org>, <palves@redhat.com>
Subject: Re: [PING] Re: [PATCH v2 3/3] PR remote/19496, timeout in forking-threads-plus-bkpt
Date: Mon, 14 Mar 2016 21:30:00 -0000 [thread overview]
Message-ID: <56E72D7D.2050605@codesourcery.com> (raw)
In-Reply-To: <56D8806A.1000505@codesourcery.com>
Ping.
Thanks,
--Don
On 3/3/2016 10:20 AM, Don Breazeal wrote:
> Ping.
> I checked, the patch still applies cleanly to mainline.
> Thanks
> --Don
>
> On 2/25/2016 9:29 AM, Don Breazeal wrote:
>> Ping
>> Thanks,
>> --Don
>>
>> On 2/10/2016 4:28 PM, Don Breazeal wrote:
>>> On 2/1/2016 12:09 PM, Pedro Alves wrote:
>>>> On 02/01/2016 07:29 PM, Don Breazeal wrote:
>>>>> On 2/1/2016 4:05 AM, Pedro Alves wrote:
>>>>
>>>>> Hi Pedro,
>>> ---snip---
>>>>> A fork event was reported to GDB before GDB knew about the parent thread,
>>>>> followed immediately by a breakpoint event in a different thread. The
>>>>> parent thread was subsequently added via remote_notice_new_inferior in
>>>>> process_stop_reply, but when the thread was added the thread_info.state
>>>>> was set to THREAD_STOPPED. The fork event was then handled correctly,
>>>>> but when the fork parent was resumed via a call to keep_going, the state
>>>>> was unchanged.
>>>>
>>>> Since this is non-stop, then it sounds to me like the bug is that the
>>>> thread should have been added in THREAD_RUNNING state.
>>>>
>>>> Consider that infrun may be pulling target events out of the target_ops
>>>> backend into its own event queue, but, not process them immediately.
>>>>
>>>> E.g., infrun may be stopping all threads temporarily for a step-over-breakpoint
>>>> operation for thread A (stop_all_threads). The waitstatus of all threads
>>>> is thus left pending in the thread structure (save_status), including the
>>>> fork event of thread B. Right at this point, if the user
>>>> does "info threads", that should show thread B (the fork parent) running,
>>>> not stopped, even if internally, gdb is holding it paused for a little bit.
>>>>
>>>
>>> Hi Pedro,
>>> Here is a new patch that adds the threads with the state set to
>>> THREAD_RUNNING for fork events.
>>> Thanks!
>>> --Don
>>>
>>> This patch addresses a failure in
>>> gdb.threads/forking-threads-plus-breakpoint.exp:
>>>
>>> FAIL: gdb.threads/forking-threads-plus-breakpoint.exp: cond_bp_target=1:
>>> detach_on_fork=on: inferior 1 exited (timeout)
>>>
>>> Cause:
>>> A fork event was reported to GDB before GDB knew about the parent thread,
>>> followed immediately by a breakpoint event in a different thread. The
>>> parent thread was subsequently added via remote_notice_new_inferior in
>>> process_stop_reply, but when the thread was added the thread_info.state
>>> was set to THREAD_STOPPED. The fork event was then handled correctly,
>>> but when the fork parent was resumed via a call to keep_going, the state
>>> was unchanged.
>>>
>>> The breakpoint event was then handled, which caused all the non-breakpoint
>>> threads to be stopped. When the breakpoint thread was resumed, all the
>>> non-breakpoint threads were resumed via infrun.c:restart_threads. Our old
>>> fork parent wasn't restarted, because it still had thread_info.state set to
>>> THREAD_STOPPED. Ultimately the program under debug hung waiting for a
>>> pthread_join while the old fork parent was stopped forever by GDB.
>>>
>>> Fix:
>>> Make sure to add the fork parent thread in the THREAD_RUNNING state by
>>> calling remote_notice_new_inferior with RUNNING set to 1 when processing
>>> a fork stop reply.
>>>
>>> Tested on x86_64 Linux and Nios II Linux target with x86 Linux host.
>>>
>>> gdb/ChangeLog:
>>> 2016-02-10 Don Breazeal <donb@codesourcery.com>
>>>
>>> * remote.c (process_stop_reply): Call remote_notice_new_inferior
>>> with RUNNING set to 1 when handling fork events.
>>>
>>> ---
>>> gdb/remote.c | 9 ++++++++-
>>> 1 file changed, 8 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/gdb/remote.c b/gdb/remote.c
>>> index f09a06e..ab750a7 100644
>>> --- a/gdb/remote.c
>>> +++ b/gdb/remote.c
>>> @@ -6818,7 +6818,14 @@ process_stop_reply (struct stop_reply *stop_reply,
>>> VEC_free (cached_reg_t, stop_reply->regcache);
>>> }
>>>
>>> - remote_notice_new_inferior (ptid, 0);
>>> + /* If a fork event arrived before we knew about the parent thread,
>>> + make sure to mark it as running when it is created. */
>>> + if (status->kind == TARGET_WAITKIND_FORKED
>>> + || status->kind == TARGET_WAITKIND_VFORKED)
>>> + remote_notice_new_inferior (ptid, 1);
>>> + else
>>> + remote_notice_new_inferior (ptid, 0);
>>> +
>>> remote_thr = demand_private_info (ptid);
>>> remote_thr->core = stop_reply->core;
>>> remote_thr->stop_reason = stop_reply->stop_reason;
>>>
>>
>
next prev parent reply other threads:[~2016-03-14 21:30 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-28 0:48 [PATCH 0/3] PR remote/19496, remote fork failures Don Breazeal
2016-01-28 0:48 ` [PATCH 1/3] PR remote/19496, internal err forking-threads-plus-bkpt Don Breazeal
2016-02-01 19:26 ` [pushed] Test gdb.threads/forking-threads-plus-breakpoint.exp with, displaced stepping off (Re: [PATCH 1/3] PR remote/19496, internal err forking-threads-plus-bkpt) Pedro Alves
2016-02-01 20:38 ` [PATCH 1/3] PR remote/19496, internal err forking-threads-plus-bkpt Pedro Alves
2016-02-11 0:26 ` [PATCH v2 " Don Breazeal
2016-02-12 20:15 ` Pedro Alves
2016-02-16 17:21 ` Don Breazeal
2016-01-28 0:48 ` [PATCH 3/3] PR remote/19496, timeout in forking-threads-plus-bkpt Don Breazeal
2016-02-01 12:05 ` Pedro Alves
2016-02-01 19:29 ` Don Breazeal
2016-02-01 20:09 ` Pedro Alves
2016-02-11 0:28 ` [PATCH v2 " Don Breazeal
2016-02-25 17:29 ` [PING]Re: " Don Breazeal
2016-03-03 18:20 ` [PING] " Don Breazeal
2016-03-14 21:30 ` Don Breazeal [this message]
2016-03-15 15:30 ` Pedro Alves
2016-03-16 17:29 ` Don Breazeal
2016-03-16 22:51 ` Don Breazeal
2016-03-17 10:38 ` Pedro Alves
2016-02-11 0:28 ` [PATCH v2 2/3] PR remote/19496, interrupted syscall " Don Breazeal
2016-02-25 17:28 ` Don Breazeal
2016-03-03 18:19 ` [PING] " Don Breazeal
2016-03-14 21:29 ` Don Breazeal
2016-03-15 12:55 ` Pedro Alves
2016-03-16 18:26 ` Don Breazeal
2016-03-16 18:33 ` Pedro Alves
2016-03-16 22:18 ` Don Breazeal
2016-01-28 0:48 ` [PATCH " Don Breazeal
2016-02-01 19:38 ` Pedro Alves
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=56E72D7D.2050605@codesourcery.com \
--to=donb@codesourcery.com \
--cc=gdb-patches@sourceware.org \
--cc=palves@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).