* ppc64* native-gdbserver testsuite hangs on gdb.threads/process-dies-while-handling-bp.exp @ 2017-12-19 9:17 Edjunior Machado 2017-12-19 16:27 ` Yao Qi 0 siblings, 1 reply; 8+ messages in thread From: Edjunior Machado @ 2017-12-19 9:17 UTC (permalink / raw) To: gdb-patches Hi, from the discussions that followed https://sourceware.org/ml/gdb-patches/2017-12/msg00374.html, regarding buildings that were taking much longer than the expected, noticed that gdb.threads/process-dies-while-handling-bp.exp is hanging on ppc64[le] when testing native-gdbserver, leading the testrun to take hours until it is timed out. According to git bisect, it seems it started to happen after this commit: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commit;h=173981 However, I couldn't figure out what exactly might be root cause of this behavior. Also, the same doesn't happen on default (non-gdbserver) testsuite run. Any idea/suggestion? Thanks and regards, Edjunior ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: ppc64* native-gdbserver testsuite hangs on gdb.threads/process-dies-while-handling-bp.exp 2017-12-19 9:17 ppc64* native-gdbserver testsuite hangs on gdb.threads/process-dies-while-handling-bp.exp Edjunior Machado @ 2017-12-19 16:27 ` Yao Qi 2017-12-19 17:51 ` Yao Qi 0 siblings, 1 reply; 8+ messages in thread From: Yao Qi @ 2017-12-19 16:27 UTC (permalink / raw) To: Edjunior Machado; +Cc: GDB Patches On Tue, Dec 19, 2017 at 9:17 AM, Edjunior Machado <edjunior@gmail.com> wrote: > from the discussions that followed > https://sourceware.org/ml/gdb-patches/2017-12/msg00374.html, regarding > buildings that were taking much longer than the expected, noticed that > gdb.threads/process-dies-while-handling-bp.exp is hanging on ppc64[le] when > testing native-gdbserver, leading the testrun to take hours until it is > timed out. According to git bisect, it seems it started to happen after > this commit: > > https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commit;h=173981 > > However, I couldn't figure out what exactly might be root cause of this > behavior. Also, the same doesn't happen on default (non-gdbserver) > testsuite run. Any idea/suggestion? > It is a known issue in GDB, described in PR 18749, rather than a regression, so git bisect can't tell you anything useful. Pedro fixed one GDBserver crash caused by 18749, but PR 18749 is still there. I can reproduce the timeout on gcc110, KFAIL: gdb.threads/process-dies-while-handling-bp.exp: non_stop=on: cond_bp_target=0: inferior 1 exited (timeout) (PRMS: gdb/18749) Remote debugging from host 127.0.0.1^M gdbserver: reading register 10: No such process^M ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Killing process(es): 15614^M monitor exit^M Ignoring packet error, continuing... I think some code path in GDBserver doesn't expect this error. -- Yao (齐尧) ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: ppc64* native-gdbserver testsuite hangs on gdb.threads/process-dies-while-handling-bp.exp 2017-12-19 16:27 ` Yao Qi @ 2017-12-19 17:51 ` Yao Qi 2017-12-20 15:24 ` Edjunior Machado 2018-01-16 9:12 ` Yao Qi 0 siblings, 2 replies; 8+ messages in thread From: Yao Qi @ 2017-12-19 17:51 UTC (permalink / raw) To: Edjunior Machado; +Cc: GDB Patches Yao Qi <qiyaoltc@gmail.com> writes: > It is a known issue in GDB, described in PR 18749, rather than a > regression, so git bisect can't tell you anything useful. Pedro fixed > one GDBserver crash caused by 18749, but PR 18749 is still > there. > > I can reproduce the timeout on gcc110, > > KFAIL: gdb.threads/process-dies-while-handling-bp.exp: non_stop=on: > cond_bp_target=0: inferior 1 exited (timeout) (PRMS: gdb/18749) > Remote debugging from host 127.0.0.1^M > gdbserver: reading register 10: No such process^M > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > Killing process(es): 15614^M > monitor exit^M > Ignoring packet error, continuing... > > I think some code path in GDBserver doesn't expect this error. Does this patch work for you? With this patch, process-dies-while-handling-bp.exp never timeout on gcc110 with native-gdbserver. -- Yao (齐尧) From ef027cdb366e3000dee2c713abab4f30123d9ed1 Mon Sep 17 00:00:00 2001 From: Yao Qi <yao.qi@linaro.org> Date: Tue, 19 Dec 2017 17:44:11 +0000 Subject: [PATCH] Mark register unavailable when PTRACE_PEEKUSER fails As described in PR 18749, GDB/GDBserver may get an error on accessing memory or register because the thread may disappear. However, some path doesn't expect the error. This patch fixes this problem by marking the register unavailable when PTRACE_PEEKUSER fails instead of throwing error. gdb/gdbserver: 2017-12-19 Yao Qi <yao.qi@linaro.org> PR gdb/18749 * linux-low.c (fetch_register): Call supply_register instead of error. diff --git a/gdb/gdbserver/linux-low.c b/gdb/gdbserver/linux-low.c index f6a52d5..0a52a91 100644 --- a/gdb/gdbserver/linux-low.c +++ b/gdb/gdbserver/linux-low.c @@ -5555,7 +5555,11 @@ fetch_register (const struct usrregs_info *usrregs, (PTRACE_TYPE_ARG3) (uintptr_t) regaddr, (PTRACE_TYPE_ARG4) 0); regaddr += sizeof (PTRACE_XFER_TYPE); if (errno != 0) - error ("reading register %d: %s", regno, strerror (errno)); + { + /* Mark register REGNO unavailable. */ + supply_register (regcache, regno, NULL); + return; + } } if (the_low_target.supply_ptrace_register) ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: ppc64* native-gdbserver testsuite hangs on gdb.threads/process-dies-while-handling-bp.exp 2017-12-19 17:51 ` Yao Qi @ 2017-12-20 15:24 ` Edjunior Machado 2017-12-20 16:23 ` Yao Qi 2018-01-16 9:12 ` Yao Qi 1 sibling, 1 reply; 8+ messages in thread From: Edjunior Machado @ 2017-12-20 15:24 UTC (permalink / raw) To: Yao Qi; +Cc: GDB Patches Hi Yao, thanks a lot for the patch! Testing the fix on Fedora26, confirmed that native-gdbserver no longer hangs on gdb.threads/process-dies-while-handling-bp.exp in both ppc64le and be. Unfortunately, I couldn't regtest running the complete testsuite due to another hang I'm still checking (likely caused by hw watch not working properly on such boxes). Thanks and regards, Edjunior On Tue, Dec 19, 2017 at 6:51 PM, Yao Qi <qiyaoltc@gmail.com> wrote: > Yao Qi <qiyaoltc@gmail.com> writes: > > > It is a known issue in GDB, described in PR 18749, rather than a > > regression, so git bisect can't tell you anything useful. Pedro fixed > > one GDBserver crash caused by 18749, but PR 18749 is still > > there. > > > > I can reproduce the timeout on gcc110, > > > > KFAIL: gdb.threads/process-dies-while-handling-bp.exp: non_stop=on: > > cond_bp_target=0: inferior 1 exited (timeout) (PRMS: gdb/18749) > > Remote debugging from host 127.0.0.1^M > > gdbserver: reading register 10: No such process^M > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > Killing process(es): 15614^M > > monitor exit^M > > Ignoring packet error, continuing... > > > > I think some code path in GDBserver doesn't expect this error. > > Does this patch work for you? With this patch, > process-dies-while-handling-bp.exp never timeout on gcc110 with > native-gdbserver. > > -- > Yao (齐尧) > From ef027cdb366e3000dee2c713abab4f30123d9ed1 Mon Sep 17 00:00:00 2001 > From: Yao Qi <yao.qi@linaro.org> > Date: Tue, 19 Dec 2017 17:44:11 +0000 > Subject: [PATCH] Mark register unavailable when PTRACE_PEEKUSER fails > > As described in PR 18749, GDB/GDBserver may get an error on accessing > memory or register because the thread may disappear. However, some > path doesn't expect the error. This patch fixes this problem by > marking the register unavailable when PTRACE_PEEKUSER fails instead > of throwing error. > > gdb/gdbserver: > > 2017-12-19 Yao Qi <yao.qi@linaro.org> > > PR gdb/18749 > * linux-low.c (fetch_register): Call supply_register instead of > error. > > diff --git a/gdb/gdbserver/linux-low.c b/gdb/gdbserver/linux-low.c > index f6a52d5..0a52a91 100644 > --- a/gdb/gdbserver/linux-low.c > +++ b/gdb/gdbserver/linux-low.c > @@ -5555,7 +5555,11 @@ fetch_register (const struct usrregs_info *usrregs, > (PTRACE_TYPE_ARG3) (uintptr_t) regaddr, (PTRACE_TYPE_ARG4) > 0); > regaddr += sizeof (PTRACE_XFER_TYPE); > if (errno != 0) > - error ("reading register %d: %s", regno, strerror (errno)); > + { > + /* Mark register REGNO unavailable. */ > + supply_register (regcache, regno, NULL); > + return; > + } > } > > if (the_low_target.supply_ptrace_register) > ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: ppc64* native-gdbserver testsuite hangs on gdb.threads/process-dies-while-handling-bp.exp 2017-12-20 15:24 ` Edjunior Machado @ 2017-12-20 16:23 ` Yao Qi 2017-12-20 21:35 ` Yao Qi 0 siblings, 1 reply; 8+ messages in thread From: Yao Qi @ 2017-12-20 16:23 UTC (permalink / raw) To: Edjunior Machado; +Cc: GDB Patches On Wed, Dec 20, 2017 at 3:23 PM, Edjunior Machado <edjunior@gmail.com> wrote: > thanks a lot for the patch! Testing the fix on Fedora26, confirmed that > native-gdbserver no longer hangs on > gdb.threads/process-dies-while-handling-bp.exp in both ppc64le and be. > > Unfortunately, I couldn't regtest running the complete testsuite due to > another hang I'm still checking (likely caused by hw watch not working > properly on such boxes). > Is it gdb.base/watchpoints.exp? My regression test running on gcc110 is very slow, blocked by gdb.base/watchpoints.exp. The test needs two HW watchpoints, but ppc only has one HW watchpoint register. GDB native can do resource counting, so it is smart enough to switch to SW wathcpoint if there is not enough HW watchpoint registers. However, GDB remote can *not* do resource counting, so GDB fails to insert watchpoints, and all the following tests timeout. -- Yao (齐尧) ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: ppc64* native-gdbserver testsuite hangs on gdb.threads/process-dies-while-handling-bp.exp 2017-12-20 16:23 ` Yao Qi @ 2017-12-20 21:35 ` Yao Qi 2017-12-21 16:02 ` Edjunior Machado 0 siblings, 1 reply; 8+ messages in thread From: Yao Qi @ 2017-12-20 21:35 UTC (permalink / raw) To: Edjunior Machado; +Cc: GDB Patches On Wed, Dec 20, 2017 at 4:23 PM, Yao Qi <qiyaoltc@gmail.com> wrote: > Is it gdb.base/watchpoints.exp? My regression test running on gcc110 > is very slow, blocked by gdb.base/watchpoints.exp. The test needs two > HW watchpoints, but ppc only has one HW watchpoint register. GDB > native can do resource counting, so it is smart enough to switch to > SW wathcpoint if there is not enough HW watchpoint registers. However, > GDB remote can *not* do resource counting, so GDB fails to insert > watchpoints, and all the following tests timeout. > Looks ppc64-linux gdbserver doesn't support watchpoint, so we need to improve test cases to probe hw watchpoint support. See test "set probe hw watchpoint" in watchpoint-stops-at-right-insn.exp. -- Yao (齐尧) ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: ppc64* native-gdbserver testsuite hangs on gdb.threads/process-dies-while-handling-bp.exp 2017-12-20 21:35 ` Yao Qi @ 2017-12-21 16:02 ` Edjunior Machado 0 siblings, 0 replies; 8+ messages in thread From: Edjunior Machado @ 2017-12-21 16:02 UTC (permalink / raw) To: Yao Qi; +Cc: GDB Patches Hi Yao, On Wed, Dec 20, 2017 at 10:35 PM, Yao Qi <qiyaoltc@gmail.com> wrote: > On Wed, Dec 20, 2017 at 4:23 PM, Yao Qi <qiyaoltc@gmail.com> wrote: > > Is it gdb.base/watchpoints.exp? My regression test running on gcc110 > > is very slow, blocked by gdb.base/watchpoints.exp. The test needs two > > HW watchpoints, but ppc only has one HW watchpoint register. GDB > > native can do resource counting, so it is smart enough to switch to > > SW wathcpoint if there is not enough HW watchpoint registers. However, > > GDB remote can *not* do resource counting, so GDB fails to insert > > watchpoints, and all the following tests timeout. > > > exactly, gdb.base/watchpoints.exp is the hanging testcase now. > > Looks ppc64-linux gdbserver doesn't support watchpoint, so we need > to improve test cases to probe hw watchpoint support. See > test "set probe hw watchpoint" in watchpoint-stops-at-right-insn.exp. > Agreed, ppc64[le] gdbserver currently does not implement hw watchpoint support; however, despite the high number of failures on the mentioned test (and possibly others) because of that, from what I could git-bisect, it didn't hang the native-gdbserver testrun until commit c65d6b55b3a592906c470c566f57ad8ceacc1605. Thanks and regards, Edjunior > > -- > Yao (齐尧) > ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: ppc64* native-gdbserver testsuite hangs on gdb.threads/process-dies-while-handling-bp.exp 2017-12-19 17:51 ` Yao Qi 2017-12-20 15:24 ` Edjunior Machado @ 2018-01-16 9:12 ` Yao Qi 1 sibling, 0 replies; 8+ messages in thread From: Yao Qi @ 2018-01-16 9:12 UTC (permalink / raw) To: Edjunior Machado; +Cc: GDB Patches Yao Qi <qiyaoltc@gmail.com> writes: > As described in PR 18749, GDB/GDBserver may get an error on accessing > memory or register because the thread may disappear. However, some > path doesn't expect the error. This patch fixes this problem by > marking the register unavailable when PTRACE_PEEKUSER fails instead > of throwing error. > > gdb/gdbserver: > > 2017-12-19 Yao Qi <yao.qi@linaro.org> > > PR gdb/18749 > * linux-low.c (fetch_register): Call supply_register instead of > error. I pushed it in to master. -- Yao (齐尧) ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2018-01-16 9:12 UTC | newest] Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2017-12-19 9:17 ppc64* native-gdbserver testsuite hangs on gdb.threads/process-dies-while-handling-bp.exp Edjunior Machado 2017-12-19 16:27 ` Yao Qi 2017-12-19 17:51 ` Yao Qi 2017-12-20 15:24 ` Edjunior Machado 2017-12-20 16:23 ` Yao Qi 2017-12-20 21:35 ` Yao Qi 2017-12-21 16:02 ` Edjunior Machado 2018-01-16 9:12 ` Yao Qi
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).