From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id 4GuxB7XMI2VpKSkAWB0awg (envelope-from ) for ; Mon, 09 Oct 2023 05:49:41 -0400 Authentication-Results: simark.ca; dkim=pass (1024-bit key; unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=JgZETMzt; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 1B9C31E0C1; Mon, 9 Oct 2023 05:49:41 -0400 (EDT) Received: from server2.sourceware.org (server2.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 099DE1E047 for ; Mon, 9 Oct 2023 05:49:39 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id AEBAA3858436 for ; Mon, 9 Oct 2023 09:49:38 +0000 (GMT) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTPS id 8AE3C3858D1E for ; Mon, 9 Oct 2023 09:49:27 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 8AE3C3858D1E Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1696844967; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=8Rk2ZBcap/44M/c7pFE8YAdSAQal6XVNTZ+Pb1ZBpik=; b=JgZETMztMBZK2Ij+VEwgvbzW47XJu58duOpOpxM3z6ovwLaBpsnSEexPOOa02dJ8OmiHjo E+6DeeIhAFPbNznOJzEtlNjZ6+toenQo3OLbf5i9/5AOVOTTLadeBlKbSbNBB1INyrmcsF 5rK4gNA62idi2Kga82Q1R9wz/ABYthw= Received: from mail-ed1-f72.google.com (mail-ed1-f72.google.com [209.85.208.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-147-NRQl4ISLNWuP7Kc4OtOSIg-1; Mon, 09 Oct 2023 05:49:25 -0400 X-MC-Unique: NRQl4ISLNWuP7Kc4OtOSIg-1 Received: by mail-ed1-f72.google.com with SMTP id 4fb4d7f45d1cf-538d651bc0eso3760788a12.0 for ; Mon, 09 Oct 2023 02:49:25 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1696844964; x=1697449764; h=mime-version:message-id:date:references:in-reply-to:subject:cc:to :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=8Rk2ZBcap/44M/c7pFE8YAdSAQal6XVNTZ+Pb1ZBpik=; b=R9SIWjIUYjfCuCftVZ+EbzxvjfnPABfT1xKOx5L3zkETuSoi+l2Gp6GUijKRwUabBq g86oRoxR8WgU8K9SH9qcLk0QT5O5pdoMfRYUy6rVNALOHlvkMi4zmtcPeceNz9wBJrp2 EvPu8KoluGaZs+Daxf8J+AvTJ9anuj1BGV02XCFHHZOv5/L/P2RQqc/Pcpk0dvVoS9PR G2XIynIu/3SOMYkFAM55g4ds99TtwB3YCR2ucEpECxoUQTC/md5FR6TmOR1iDKUZuPFw 9HdCc8Zifkv+2Nai2Rf9XQkEKJa27gjuH/WLhx1dfFE2QC++SegD8vF4iGYqQt9EC6Tj kD4g== X-Gm-Message-State: AOJu0Yzb+EX6KCNS6iYPkuTm9yqJJHS5mKrzyG7QvcvP+0E0NXowGFHO BYlnPWAZ0YfuRGJBiGhfOKTVZ5d6DFKTAr8VEuW6XapduibfKfww0Etz4jl/f6RbvjxGOJ7MuwY AgGP/HjgO88o5alGUe5PkgJvNZZQp1A== X-Received: by 2002:aa7:da8a:0:b0:531:9c1:8262 with SMTP id q10-20020aa7da8a000000b0053109c18262mr13099939eds.8.1696844964518; Mon, 09 Oct 2023 02:49:24 -0700 (PDT) X-Google-Smtp-Source: AGHT+IEmXy6dCbXhzJ1hcpwHa+oJ3U4pMiaMKKTpke4pCF/A9jj/mNQLR7Nj8oXk1BlAuju4ZuPBsg== X-Received: by 2002:aa7:da8a:0:b0:531:9c1:8262 with SMTP id q10-20020aa7da8a000000b0053109c18262mr13099935eds.8.1696844964193; Mon, 09 Oct 2023 02:49:24 -0700 (PDT) Received: from localhost ([31.111.84.209]) by smtp.gmail.com with ESMTPSA id p26-20020aa7d31a000000b00534ac155da7sm5881988edq.29.2023.10.09.02.49.23 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 09 Oct 2023 02:49:23 -0700 (PDT) From: Andrew Burgess To: Thiago Jung Bauermann Cc: Simon Marchi , gdb-patches@sourceware.org Subject: Re: [PATCH] gdb/testsuite: Bump up 'match_max' In-Reply-To: <87mswvlcca.fsf@linaro.org> References: <20231003195338.334948-1-thiago.bauermann@linaro.org> <87ttr6m2j7.fsf@linaro.org> <87lechn63m.fsf@linaro.org> <87v8bjsn0p.fsf@redhat.com> <87mswvlcca.fsf@linaro.org> Date: Mon, 09 Oct 2023 10:49:22 +0100 Message-ID: <874jj0dt25.fsf@redhat.com> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-Spam-Status: No, score=-11.7 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H4, RCVD_IN_MSPIKE_WL, 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+public-inbox=simark.ca@sourceware.org Thiago Jung Bauermann writes: > Hello Andrew, > > Andrew Burgess writes: > >> Thiago Jung Bauermann via Gdb-patches >> writes: >> >>> Simon Marchi writes: >>> >>>> On 2023-10-04 18:43, Thiago Jung Bauermann wrote: >>>>> >>>>> Hello Simon, >>>>> >>>>> Thanks for looking into this. >>>>> >>>>> Simon Marchi writes: >>>>> >>>> The "maint info line-table" test is specifically written in a way to >>>> deal with large output. It uses gdb_test_multiple with different -re >>>> patterns to match the different expected lines. expect reads some >>>> output from GDB, then tries to match any -re line. If there's a match, >>>> the text that matched is removed from the expect buffer. When there >>>> isn't enough data in the buffer, expect reads more GDB output. This >>>> way, we consume the GDB output line by line and avoid having all the >>>> huge output of the command in the buffer at the same time. >>>> >>>> See this commit: >>>> >>>> https://gitlab.com/gnutools/binutils-gdb/-/commit/f610ab6d3cbab5d8b8ef3f3a93dd81a800ec5725 >>>> >>>> I added some "puts" in each -re clause, to see which matched (see diff >>>> at the end). With "make check", it looks fine, this -re (which matches >>>> table entries) gets matched often: >>>> >>>> -re "^$decimal\[ \t\]+$decimal\[ \t\]+$hex\[ \t\]+$hex\[^\r\n\]*\r\n" >>>> >>>> But with "make check-read1", it doesn't get matched and we accumulate >>>> lots of output in the buffer. I follow the test execution with `tail -F >>>> testsuite/gdb.log` on another terminal, and I see the output coming in >>>> slower and slower (presumably because expect tries to match our patterns >>>> on an ever growing buffer). >>>> >>>> So I think this is what you should dig into, why doesn't this -re get >>>> matched with read1. Note that the ^ at the beginning of the regex means >>>> that this regex will match only against some output at the very >>>> beginning of the buffer. So if there is some unmatched output in the >>>> buffer before what this line intends to match, it won't match. >>>> >>>> The culprits are likely the regexes that finish with an unbounded >>>> repetition like [^\r\n]*. When characters are read one by one in the >>>> buffer, the regex can match early and leave something in the buffer that >>>> it would have otherwise matched, if the reads were done in big chunks as >>>> usual (this is precisely the kind of issue that read1 means to uncover). >>>> Those regexes would need to be modified to consume the entire line, even >>>> with read1. >>> >>> Thank you for the detailed explanation and for the debug patch! I'll dig >>> further into it and see if I can fix the testcase. >> >> The patch below is what you are looking for. > > Indeed it is! I was just going to start digging into this issue. Thank > you very much for fixing it. > > I tested it on the machines I mentioned before, and all tests pass in > all of them. It even runs a lot faster now, too. > > Tested-by: Thiago Jung Bauermann Thanks. Pushed the patch below. Thanks, Andrew --- commit 2f349e7d2ac51d29994db57498accd38f893f200 Author: Andrew Burgess Date: Fri Oct 6 18:01:42 2023 +0100 gdb/testsuite: match complete lines in gdb.base/maint.exp This thread: https://inbox.sourceware.org/gdb-patches/20231003195338.334948-1-thiago.bauermann@linaro.org/ pointed out that within gdb.base/maint.exp, some regexps within a gdb_test_multiple were failing to match a complete line, while later regexps within the gdb_test_multiple made use of the '^' anchor, and so assumed that earlier lines had been completely matched and removed from expect's buffer. When testing with READ1 set this assumption was failing. Fix this by extending the offending patterns with a trailing '\r\n'. Tested-by: Thiago Jung Bauermann diff --git a/gdb/testsuite/gdb.base/maint.exp b/gdb/testsuite/gdb.base/maint.exp index c05d0987e7f..d24b0affbaf 100644 --- a/gdb/testsuite/gdb.base/maint.exp +++ b/gdb/testsuite/gdb.base/maint.exp @@ -386,11 +386,11 @@ gdb_test "maint" \ set saw_srcfile 0 gdb_test_multiple "maint info line-table" \ "maint info line-table w/o a file name" { - -re "symtab: \[^\n\r\]+${srcfile} \\(\\(struct symtab \\*\\) $hex\\)\r\nlinetable: \\(\\(struct linetable \\*\\) $hex\\):\r\nINDEX\[ \t\]+LINE\[ \t\]+REL-ADDRESS\[ \t\]+UNREL-ADDRESS\[^\r\n\]*" { + -re "symtab: \[^\n\r\]+${srcfile} \\(\\(struct symtab \\*\\) $hex\\)\r\nlinetable: \\(\\(struct linetable \\*\\) $hex\\):\r\nINDEX\[ \t\]+LINE\[ \t\]+REL-ADDRESS\[ \t\]+UNREL-ADDRESS\[^\r\n\]*\r\n" { set saw_srcfile 1 exp_continue } - -re "symtab: \[^\n\r\]+ \\(\\(struct symtab \\*\\) $hex\\)\r\nlinetable: \\(\\(struct linetable \\*\\) $hex\\):\r\nINDEX\[ \t\]+LINE\[ \t\]+REL-ADDRESS\[ \t\]+UNREL-ADDRESS\[^\r\n\]*" { + -re "symtab: \[^\n\r\]+ \\(\\(struct symtab \\*\\) $hex\\)\r\nlinetable: \\(\\(struct linetable \\*\\) $hex\\):\r\nINDEX\[ \t\]+LINE\[ \t\]+REL-ADDRESS\[ \t\]+UNREL-ADDRESS\[^\r\n\]*\r\n" { # Match each symtab to avoid overflowing expect's buffer. exp_continue }