From patchwork Fri Jan 12 19:11:16 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Pedro Alves X-Patchwork-Id: 25367 Received: (qmail 27736 invoked by alias); 12 Jan 2018 19:11:22 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Delivered-To: mailing list gdb-patches@sourceware.org Received: (qmail 27130 invoked by uid 89); 12 Jan 2018 19:11:21 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-26.9 required=5.0 tests=BAYES_00, GIT_PATCH_0, GIT_PATCH_1, GIT_PATCH_2, GIT_PATCH_3, KAM_SHORT, SPF_HELO_PASS, T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 spammy= X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 12 Jan 2018 19:11:19 +0000 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 2C11176525; Fri, 12 Jan 2018 19:11:18 +0000 (UTC) Received: from [127.0.0.1] (ovpn04.gateway.prod.ext.ams2.redhat.com [10.39.146.4]) by smtp.corp.redhat.com (Postfix) with ESMTP id 34A6036F9; Fri, 12 Jan 2018 19:11:17 +0000 (UTC) Subject: [pushed + testcase] Re: [PATCH] Fix GDB hang with remote after error from resume To: Andreas Arnez , gdb-patches@sourceware.org References: From: Pedro Alves Message-ID: <7eccd434-6f47-590e-e53f-32076e99c98b@redhat.com> Date: Fri, 12 Jan 2018 19:11:16 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: On 01/10/2018 04:56 PM, Andreas Arnez wrote: > Since this commit -- > > Fix PR18360 - internal error when using "interrupt -a" > (https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commit;h=c65d6b55) > > -- the testsuite shows long delays on s390 with native-gdbserver when > executing certain tests, such as watchpoints.exp. These hangs have been > discussed before in the context of buildbot problems, see here: > > https://sourceware.org/ml/gdb-patches/2017-12/msg00413.html > > The problem can easily be triggered by stopping on a breakpoint, then > setting impossible watchpoints, and finally doing "continue". Then, after > having set the step-over state (in keep_going_pass_signal in infrun.c), > GDB tries to insert breakpoints and watchpoints into the inferior. This > fails, and the "continue" command is aborted. But the step-over state is > not cleared in this case, which causes future step-over attempts to be > skipped since GDB thinks that "we already have an in-line step-over > operation ongoing" (see start_step_over in infrun.c). Thus the next > "continue" just goes on to wait for events from the remote, which will > never occur. > Thanks much for the fix. > The problem can also be reproduced on amd64 with native-gdbserver, using > the following change to watchpoints.exp: > > -- >8 -- > --- a/gdb/testsuite/gdb.base/watchpoints.exp > +++ b/gdb/testsuite/gdb.base/watchpoints.exp > @@ -61,2 +61,3 @@ with_test_prefix "before inferior start" { > gdb_test "watch ival3" ".*" "" > + gdb_test "watch *(char \[256\] *) main" > > -- >8 -- > One question I had with this is why would it only trigger with native-gdbserver. After debugging a bit, it was obvious -- the reason is simply that native debugging uses displaced stepping by default, unlike remote debugging, because native debugging enables all-stop-on-top-of-non-stop by default. I never got around to flipping that on ("maint set target-non-stop on") by default with remote debugging. I've pushed in your patch to both master and 8.1, along with this follow up commit adding a testcase. From 1d17025506de70cb1d9d5b7a5654e40ce689bf26 Mon Sep 17 00:00:00 2001 From: Pedro Alves Date: Fri, 12 Jan 2018 18:59:40 +0000 Subject: [PATCH] Add testcase for GDB hang fixed by previous commit This adds a testcase for the previous commit. The regression was related to in-line step overs. The reason we didn't see it on native x86-64/s390 GNU/Linux testing is that native debugging uses displaced stepping by default (because native debugging defaults to "maint set target-non-stop on"), unlike remote debugging. So in order to trigger the bug with native debugging as well, the testcase disables displaced stepping explicitly. Also, instead of using watchpoints to trigger the regression, the testcase uses a breakpoint at address 0, which should be more portable. gdb/testsuite/ChangeLog: 2018-01-12 Pedro Alves * gdb.base/continue-after-aborted-step-over.c: New. * gdb.base/continue-after-aborted-step-over.exp: New. --- gdb/testsuite/ChangeLog | 5 ++ .../gdb.base/continue-after-aborted-step-over.c | 29 ++++++++ .../gdb.base/continue-after-aborted-step-over.exp | 87 ++++++++++++++++++++++ 3 files changed, 121 insertions(+) create mode 100644 gdb/testsuite/gdb.base/continue-after-aborted-step-over.c create mode 100644 gdb/testsuite/gdb.base/continue-after-aborted-step-over.exp diff --git a/gdb/testsuite/ChangeLog b/gdb/testsuite/ChangeLog index 7d7c389d98d..90ffb4fa443 100644 --- a/gdb/testsuite/ChangeLog +++ b/gdb/testsuite/ChangeLog @@ -1,3 +1,8 @@ +2018-01-12 Pedro Alves + + * gdb.base/continue-after-aborted-step-over.c: New. + * gdb.base/continue-after-aborted-step-over.exp: New. + 2018-01-11 Pedro Alves PR remote/22597 diff --git a/gdb/testsuite/gdb.base/continue-after-aborted-step-over.c b/gdb/testsuite/gdb.base/continue-after-aborted-step-over.c new file mode 100644 index 00000000000..7252648084e --- /dev/null +++ b/gdb/testsuite/gdb.base/continue-after-aborted-step-over.c @@ -0,0 +1,29 @@ +/* This testcase is part of GDB, the GNU debugger. + + Copyright 2018 Free Software Foundation, Inc. + + This program is free software; you can redistribute it and/or modify + it under the terms of the GNU General Public License as published by + the Free Software Foundation; either version 3 of the License, or + (at your option) any later version. + + This program is distributed in the hope that it will be useful, + but WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + GNU General Public License for more details. + + You should have received a copy of the GNU General Public License + along with this program. If not, see . */ + +void +function (void) +{ +} + +int +main () +{ + function (); + + return 0; +} diff --git a/gdb/testsuite/gdb.base/continue-after-aborted-step-over.exp b/gdb/testsuite/gdb.base/continue-after-aborted-step-over.exp new file mode 100644 index 00000000000..297cb638587 --- /dev/null +++ b/gdb/testsuite/gdb.base/continue-after-aborted-step-over.exp @@ -0,0 +1,87 @@ +# Copyright 2018 Free Software Foundation, Inc. + +# This program is free software; you can redistribute it and/or modify +# it under the terms of the GNU General Public License as published by +# the Free Software Foundation; either version 3 of the License, or +# (at your option) any later version. +# +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with this program. If not, see . + +# This testcase is a regression test for a regression in the in-line +# step-over machinery. If a resumption that starts a step-over +# failed, a following resumption would make GDB hang forever: +# +# (gdb) b *0 +# Breakpoint 2 at 0x0 +# continue +# Continuing. +# Warning: +# Cannot insert breakpoint 2. +# Cannot access memory at address 0x0 +# +# Command aborted. +# delete breakpoints +# Delete all breakpoints? (y or n) y +# (gdb) b function +# Breakpoint 3 at 0x40048b: file test.c, line 33. +# continue +# Continuing. +# *GDB hangs forever* + +standard_testfile + +if {[build_executable "failed to prepare" $testfile $srcfile debug]} { + return -1 +} + +# DISPLACED indicates whether to use displaced-stepping. +proc do_test {displaced} { + global gdb_prompt decimal + global srcfile binfile + + clean_restart $binfile + + gdb_test_no_output "set displaced-stepping $displaced" + + if ![runto_main] { + fail "run to main" + return -1 + } + + # We rely on not being able to set a breakpoint at 0, as proxy for + # any kind of breakpoint insertion failure. If we can examine + # what's at memory address 0, it is possible that we could also + # execute it. + if [is_address_zero_readable] { + untested "memory at address 0 is possibly executable" + return + } + + # Set a breakpoint that fails to insert. + gdb_test "b *0" "Breakpoint $decimal at 0x0" + + gdb_test "continue" \ + "Command aborted\\." \ + "continue aborts" + + # Delete the "bad" breakpoint and try continuing again. + delete_breakpoints + gdb_test "b function" "Breakpoint $decimal .*$srcfile.*" + + gdb_test "continue" \ + "Breakpoint $decimal, function \\(\\) at .*$srcfile:.*" \ + "continue to function" +} + +# This testcase exercises a regression with the in-line step-over +# machinery. So make sure this runs with displaced stepping disabled, +# and for good measure, also try with displaced stepping enabled. +foreach_with_prefix displaced-stepping {"off" "on"} { + do_test ${displaced-stepping} +}