From patchwork Mon Oct 21 09:56:09 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Metzger, Markus T" X-Patchwork-Id: 99263 Return-Path: X-Original-To: patchwork@sourceware.org Delivered-To: patchwork@sourceware.org Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 190F13858027 for ; Mon, 21 Oct 2024 09:57:01 +0000 (GMT) X-Original-To: gdb-patches@sourceware.org Delivered-To: gdb-patches@sourceware.org Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.17]) by sourceware.org (Postfix) with ESMTPS id ED32F3858CDB for ; Mon, 21 Oct 2024 09:56:21 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org ED32F3858CDB Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=intel.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=intel.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org ED32F3858CDB Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=198.175.65.17 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1729504590; cv=none; b=NVpUTSNJjteRJLUS6zjjFN488CB0x7tecrA7wYJ9GLs/iwdfwxkVzQ1mw/E+KF2imCF+6KhIw5FrwuK7xRa9EFOkaQuNLi8RHDSTnrgXuM/QC1m7YZSNMtDkgOtEkhbCN8ZfAHVTIDilCBmWzqdtu0ISqdBv+ycJINCe69D2QNo= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1729504590; c=relaxed/simple; bh=+mwaaDUKP98rhMkLLrx+LP5NGbjv0gZNEqRW6i99eE8=; h=DKIM-Signature:From:To:Subject:Date:Message-Id:MIME-Version; b=fGXTzQgPhLfo7s/1fbjrkkGkaGzROu5ceFtmqdE+zVyap6Nc/rfe5aMBTooh1l3GDVO3ZK9vHUdPIwwqXzy8tIeQ90xHjVjF1komTRACSFigCgpikOo1X2QOLRPwk/c0IdsjsSIR2A2cqlhkacG26Yjkjk4j6BRQDe9EEQAG+Og= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1729504582; x=1761040582; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=+mwaaDUKP98rhMkLLrx+LP5NGbjv0gZNEqRW6i99eE8=; b=IEMuKcUgIJMHXBhraFJpRkyj9OE8Mj8lA+QP180mFVavON2f74p+/HXa dZTOJeLX6tJ4q6yTDXez/PN/NGKNg3Z+kIyQDRv5GnHdhIvkdFkGoHy8x LbKbCjmHRvCvB8PjzlbiLVT2dMS2QvwnuLl2XdZCtemd9zeWJrub2i3CR /fl7g2R4lb5lGCQ46cfViOEhKA6HudHbVONTH49zQkcaZkSDqb7hr0Mdk uyrjI/MlEOcmq9Ymo5lJ801+CV2lrcXpM6caEjRSfDLzRNE6u1ddmFWOK 8oPRZ6uZCkQJcaG0wKipd2RVsPoM65itv+xJHh96nH7/woXgPyZPp5XXd g==; X-CSE-ConnectionGUID: xf67hj5/Q6KcAvDA0q5rUA== X-CSE-MsgGUID: OR+N9L9fSiSIYFnzzU0OOQ== X-IronPort-AV: E=McAfee;i="6700,10204,11231"; a="29078006" X-IronPort-AV: E=Sophos;i="6.11,220,1725346800"; d="scan'208";a="29078006" Received: from fmviesa004.fm.intel.com ([10.60.135.144]) by orvoesa109.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 21 Oct 2024 02:56:21 -0700 X-CSE-ConnectionGUID: neHTkRUbTpWWEl0swdI5mw== X-CSE-MsgGUID: dcM/oLAhTuSJgopNXjos3g== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.11,220,1725346800"; d="scan'208";a="84103236" Received: from gkldtt-dev-004.igk.intel.com (HELO localhost) ([10.123.221.202]) by fmviesa004-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 21 Oct 2024 02:56:19 -0700 From: Markus Metzger To: gdb-patches@sourceware.org Cc: aburgess@redhat.com, Guinevere Larsen Subject: [PATCH v6 2/4] gdb, infrun, record: fix hang when step-over fails with no-history Date: Mon, 21 Oct 2024 09:56:09 +0000 Message-Id: <20241021095611.1126744-3-markus.t.metzger@intel.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20241021095611.1126744-1-markus.t.metzger@intel.com> References: <20241021095611.1126744-1-markus.t.metzger@intel.com> MIME-Version: 1.0 X-Spam-Status: No, score=-9.8 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, KAM_SHORT, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: gdb-patches-bounces~patchwork=sourceware.org@sourceware.org When trying to step over a breakpoint at the end of the trace while another thread is replaying, the step-over will fail with no-history. This does not clear step_over_info so a subsequent resume will cause GDB to not resume the thread and expect a SIGTRAP to complete the step-over. This will never come causing GDB to hang in the wait-for-event poll. This is a variant of the issue fixed in the parent commit. That commit addressed the issue for a single-threaded process and fixed an issue with reverse/replay stepping in general. This commit addresses the issue for a multi-threaded process. In this case, the single-step does not complete. Finish an in-flight step-over when a thread stopped with NO_HISTORY. Since we did not move, we will simply start the step-over again. Hannes Domani reported that this fixes PR gdb/31353. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31353 Reviewed-By: Guinevere Larsen --- gdb/infrun.c | 12 +++ .../gdb.btrace/multi-thread-break-hang.exp | 84 +++++++++++++++++++ 2 files changed, 96 insertions(+) create mode 100644 gdb/testsuite/gdb.btrace/multi-thread-break-hang.exp diff --git a/gdb/infrun.c b/gdb/infrun.c index 23739e7c009..bad42b45a26 100644 --- a/gdb/infrun.c +++ b/gdb/infrun.c @@ -78,6 +78,8 @@ #include "disasm.h" #include "interps.h" +struct execution_control_state; + /* Prototypes for local functions */ static void sig_print_info (enum gdb_signal); @@ -6573,6 +6575,16 @@ handle_inferior_event (struct execution_control_state *ecs) return; interps_notify_no_history (); + + /* Cancel an in-flight step-over. It will not succeed since we + won't be able to step at the end of the execution history. */ + { + /* finish_step_over may call restart_threads, which may change the + current thread. make sure we leave the event thread as the + current thread. */ + scoped_restore_current_thread restore_thread; + finish_step_over (ecs); + } stop_waiting (ecs); return; } diff --git a/gdb/testsuite/gdb.btrace/multi-thread-break-hang.exp b/gdb/testsuite/gdb.btrace/multi-thread-break-hang.exp new file mode 100644 index 00000000000..932d1e71956 --- /dev/null +++ b/gdb/testsuite/gdb.btrace/multi-thread-break-hang.exp @@ -0,0 +1,84 @@ +# This testcase is part of GDB, the GNU debugger. +# +# Copyright 2024 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 . + +# Test that we cancel an in-flight step-over at the end of the execution +# history as long as some other thread is still replaying. +# +# This used to cause GDB to hang in poll (). + +require allow_btrace_tests + +standard_testfile multi-thread-step.c +if [prepare_for_testing "failed to prepare" $testfile $srcfile {debug pthreads}] { + return -1 +} + +if ![runto_main] { + return -1 +} + +# Set up breakpoints. +set bp_1 [gdb_get_line_number "bp.1" $srcfile] +set bp_2 [gdb_get_line_number "bp.2" $srcfile] + +# Trace the code between the two breakpoints. +gdb_breakpoint $srcfile:$bp_1 +gdb_continue_to_breakpoint "continue to bp.1" ".*$srcfile:$bp_1\r\n.*" + +gdb_test_no_output "record btrace" + +# We have two threads at or close to bp.1 but handled only one stop event. +# Remove the breakpoint so we do not need to deal with the 2nd event. +delete_breakpoints +gdb_breakpoint $srcfile:$bp_2 +gdb_continue_to_breakpoint "continue to bp.2" ".*$srcfile:$bp_2\r\n.*" + +# Determine the thread that reported the breakpoint. +set thread [get_integer_valueof "\$_thread" bad] + +# Determine the other thread. +set other "bad" +if { $thread == 1 } { + set other 2 +} elseif { $thread == 2 } { + set other 1 +} + +# This test requires scheduler-locking 'on' or 'step'; 'replay' would +# implicitly stop replaying, avoiding the problem; 'off' would step one +# and resume the other. +# +# With the current record-btrace implementation that steps all resumed +# threads in lock-step, 'off' might actually pass but we don't want to +# bake that behavior into tests. +gdb_test_no_output "set scheduler-locking step" + +# Start replaying the other thread. This will prevent stepping the thread +# that reported the event. +gdb_test "thread apply $other record goto begin" +gdb_test "thread apply $other info record" "Replay in progress.*" + +# We're at a breakpoint so this triggers step-over. Since we're at the +# end of the trace, the step will fail. +gdb_test "stepi" "Reached end of recorded history.*" "stepi.1" + +# We used to hang at the second step since step-over insisted on polling +# the next event. +gdb_test "stepi" "Reached end of recorded history.*" "stepi.2" + +# Do one more just in case. +gdb_test "stepi" "Reached end of recorded history.*" "stepi.3"