From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pl1-x62b.google.com (mail-pl1-x62b.google.com [IPv6:2607:f8b0:4864:20::62b]) by sourceware.org (Postfix) with ESMTPS id 708D63858439 for ; Fri, 6 Oct 2023 20:34:18 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 708D63858439 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=linaro.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=linaro.org Received: by mail-pl1-x62b.google.com with SMTP id d9443c01a7336-1c61acd1285so18814735ad.2 for ; Fri, 06 Oct 2023 13:34:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1696624457; x=1697229257; darn=sourceware.org; h=mime-version:message-id:date:in-reply-to:subject:cc:to:from :user-agent:references:from:to:cc:subject:date:message-id:reply-to; bh=isGR7qLe09PPvVYwEUCqsX/0nUuoMV4hatEg1/nG3Fk=; b=A/FgR4oN094OqOz9We8SmVErw9jhLccWa6YMSlcUIF27nB8buZBNzsYfFW0kMvhbrv JaUv6coxvOKTaEb0z0ejfG9W3ZwzBXY6qL1xtQF+OJALWQCMGZVVLc8w/K8S15GirZmS HCPobzIjBcxcsvnlCeP1m4Gj69oafIgFTosoDGEBnQ+MySb25+1+vsaAMf7oQMdLDDvx QWzA3IageRpCy6whg7Bs5VbDvBXja9LAc+cIepzbuvKns07yvs2DLdt1Tdnbg6dtO0i7 DHq7M35w/fyxzwZMqwHf4J1csUbDcRrm4tPHJS81RBPvfAIKMSZd/cgkGzCSwEo6Llkd ePfQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1696624457; x=1697229257; h=mime-version:message-id:date:in-reply-to:subject:cc:to:from :user-agent:references:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=isGR7qLe09PPvVYwEUCqsX/0nUuoMV4hatEg1/nG3Fk=; b=Ek8oeVScsf+5ksFiLZXukrnbAdxBSik0SgkAYbiiCFWnkYLMdy4gMrfwTVmX7x54Ab T8scDSIb9KiYzDuRwR1UQ4Kc0uhAIPZ/H/mn7yXbbgZTxUd1zpbrw5LPFJOqJ+Z69Rr9 qAm6SbyVxsJF4ztjRkEjVyujPTewcC6HUpAjPL8mG1Du2NBaouESmG4Iufrw/BjA8Rh6 vDFRoufKq/KxwDI6Ve9kgDWmBa4+q9yXILqK4azUARfOvYrJdMvqfUo2uFEKGw2ZgOyz A7NyzdP5t5ZVCNNLyAu26dYimWwUCxhNb1slbCs9tlT4Ntw0jSlN7raJ+EZatWayAkZ4 Jh6w== X-Gm-Message-State: AOJu0YyrWc0X/vWVhqJctKAYnFFeWABmUkk+b1ig08kWa6ir0I1xyiWV 0eMCd3tpejyUmS8J9bCEbw2/uQ== X-Google-Smtp-Source: AGHT+IHGGkgD+6vCLOk3DWfysl4fprdS9jTT0cHhzrE8i6ZKa8iBcZNcsFj+VCbJICGpySeBRLOP7w== X-Received: by 2002:a17:903:2286:b0:1c5:d8a3:8789 with SMTP id b6-20020a170903228600b001c5d8a38789mr11618824plh.4.1696624457423; Fri, 06 Oct 2023 13:34:17 -0700 (PDT) Received: from localhost ([2804:14d:7e39:8470:927f:3b0e:b309:6a0a]) by smtp.gmail.com with ESMTPSA id g8-20020a1709029f8800b001c5fc291ef9sm4320800plq.209.2023.10.06.13.34.15 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 06 Oct 2023 13:34:16 -0700 (PDT) References: <20231003195338.334948-1-thiago.bauermann@linaro.org> <87ttr6m2j7.fsf@linaro.org> <87lechn63m.fsf@linaro.org> <87v8bjsn0p.fsf@redhat.com> User-agent: mu4e 1.10.7; emacs 29.1 From: Thiago Jung Bauermann To: Andrew Burgess Cc: Simon Marchi , gdb-patches@sourceware.org Subject: Re: [PATCH] gdb/testsuite: Bump up 'match_max' In-reply-to: <87v8bjsn0p.fsf@redhat.com> Date: Fri, 06 Oct 2023 17:34:13 -0300 Message-ID: <87mswvlcca.fsf@linaro.org> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Status: No, score=-4.3 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,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 List-Id: 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 -- Thiago