From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) by sourceware.org (Postfix) with ESMTPS id 20C483857C72 for ; Wed, 16 Sep 2020 11:28:13 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 20C483857C72 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=suse.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=tdevries@suse.de X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 87497B14C for ; Wed, 16 Sep 2020 11:28:27 +0000 (UTC) Date: Wed, 16 Sep 2020 13:28:10 +0200 From: Tom de Vries To: gdb-patches@sourceware.org Subject: [committed][gdb/testsuite] Catch condition evaluation errors in gdb_assert Message-ID: <20200916112809.GA13830@delia> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.10.1 (2018-07-13) X-Spam-Status: No, score=-10.9 required=5.0 tests=BAYES_00, GIT_PATCH_0, KAM_DMARC_STATUS, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Sep 2020 11:28:14 -0000 Hi, When running test-case gdb.base/watchpoint-stops-at-right-insn.exp, we may run into a tcl error, which can be reproduced reliably using this trigger patch: ... + set hw_watch_pc "" gdb_assert {$sw_watch_pc == $hw_watch_pc} \ "hw watchpoint stops at right instruction" ... such that we have: ... ERROR: tcl error sourcing watchpoint-stops-at-right-insn.exp. ERROR: missing operand at _@_ in expression "0x4004b7 == _@_" (parsing expression "0x4004b7 == ") invoked from within "expr $sw_watch_pc == $hw_watch_pc" ("uplevel" body line 1) invoked from within "uplevel 1 expr $condition" (procedure "gdb_assert" line 6) invoked from within "gdb_assert {$sw_watch_pc == $hw_watch_pc} \ "hw watchpoint stops at right instruction"" ... A similar problem was fixed in commit 5f0e2eb79e "GDB/testsuite: Fix a catastrophic step-over-no-symbols.exp failure", by making the assert condition more robust: ... - gdb_assert {$before_addr != $after_addr} "advanced" + gdb_assert {{[string is integer -strict $before_addr] \ + && [string is integer -strict $after_addr] \ + && $before_addr != $after_addr}} "advanced" ... Fix this instead in gdb_assert, by catching errors while evaluating the assert condition. Tested on x86_64-linux. Committed to trunk. Thanks, - Tom [gdb/testsuite] Catch condition evaluation errors in gdb_assert gdb/testsuite/ChangeLog: 2020-09-16 Tom de Vries PR testsuite/26624 * lib/gdb.exp (gdb_assert): Catch errors in condition evaluation. --- gdb/testsuite/lib/gdb.exp | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/gdb/testsuite/lib/gdb.exp b/gdb/testsuite/lib/gdb.exp index 653f145c1c..59439f8e37 100644 --- a/gdb/testsuite/lib/gdb.exp +++ b/gdb/testsuite/lib/gdb.exp @@ -1689,8 +1689,8 @@ proc gdb_assert { condition {message ""} } { set message $condition } - set res [uplevel 1 expr $condition] - if {!$res} { + set code [catch {uplevel 1 expr $condition} res] + if {$code != 0 || !$res} { fail $message } else { pass $message