From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pg1-x533.google.com (mail-pg1-x533.google.com [IPv6:2607:f8b0:4864:20::533]) by sourceware.org (Postfix) with ESMTPS id 7788B3858C2F for ; Thu, 5 Oct 2023 02:41:39 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 7788B3858C2F 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-pg1-x533.google.com with SMTP id 41be03b00d2f7-578d0dcd4e1so305564a12.2 for ; Wed, 04 Oct 2023 19:41:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1696473698; x=1697078498; 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=NHmvyGlAn3l/h6HRFI44NrUtOGeErIA+XbE+m+E9XSM=; b=B+rfM+f2/FRBzZPrik2fUhqWmPHiBApvhHmcUvDFRYbz3/pzxfShaxQ9APNTud1RgO +skeXhbhAnjXXe29kt1F+TKUYKyyzwY43nWzP5NCS3RKseAnZGQkcHra5xipFmFAChC5 EfFjaSmfSK78/3hKjgvLUUL2sss1ASUd1kAEe4R/eJVToc/wEuWmNMGgSKIxBE1ZdBy0 WJb1H5vYD47Yn9AEZ+7ooYNiKGODO1exN7GqORqjMhunpnigbRYTwaUtV/6rHrE7H8N0 xBAMH/ja6cd3croiuGbvzp9/QysSi1ffe+CylWy8a1nx/6LiEqZepSaWmi3Xe4PMWVwU 72TQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1696473698; x=1697078498; 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=NHmvyGlAn3l/h6HRFI44NrUtOGeErIA+XbE+m+E9XSM=; b=u7d8le/WX4VupGjCGeCN4PFgsLR31NRf9o/PxABYZhB9WsgQd/PRypJsTWlH7o8LcE EVK3ozGv4ruFPFwj8ErIc7s6cR1OGUDm0sFWZo+oK7DCXYRARWvaqz7Qv6BFh9xU3zJ/ Uty/tswrbR3tDRmuPrgqQ/FfZs8KGeVDA0UyDMyPOCMwY4n2MSAgTR6JoAq5DyeovUrJ AhO+gXqz9+P8IMCUJv6k7GCksBuHzgo8lnkAAKFzENdejy3EfkEGvr7sq78XgkQEM3mv r/yAMNE9TaW4qhXD2LhdxJDkvKd//vduwHLHON3MfHjm9zRz8tuvmUquhikKQqOjjdVA fMlQ== X-Gm-Message-State: AOJu0YxrI+DRXJQSBcPEKZpNv6ShSEE9fGP0ikNDfyuv3lc2wT0DzZLY PfGbwPpj9YZvzGUbhXQlS1ypEw== X-Google-Smtp-Source: AGHT+IGNYgiGQ8TKGBJnExaKCT53GV1/LK5Rq1A1/7T/KLjhPObSR9ZT2eMHS5ZVo9zHNC9cWbstvg== X-Received: by 2002:a17:90b:4a48:b0:274:6cd3:a533 with SMTP id lb8-20020a17090b4a4800b002746cd3a533mr3860561pjb.20.1696473697572; Wed, 04 Oct 2023 19:41:37 -0700 (PDT) Received: from localhost ([2804:14d:7e39:8470:2dfa:6486:a698:5ba9]) by smtp.gmail.com with ESMTPSA id b7-20020a17090a6ac700b0027768125e24sm2248338pjm.39.2023.10.04.19.41.35 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 04 Oct 2023 19:41:36 -0700 (PDT) References: <20231003195338.334948-1-thiago.bauermann@linaro.org> <87ttr6m2j7.fsf@linaro.org> User-agent: mu4e 1.10.7; emacs 29.1 From: Thiago Jung Bauermann To: Simon Marchi Cc: gdb-patches@sourceware.org Subject: Re: [PATCH] gdb/testsuite: Bump up 'match_max' In-reply-to: Date: Wed, 04 Oct 2023 23:41:33 -0300 Message-ID: <87lechn63m.fsf@linaro.org> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Status: No, score=-11.4 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,GIT_PATCH_0,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: Simon Marchi writes: > On 2023-10-04 18:43, Thiago Jung Bauermann wrote: >> >> Hello Simon, >> >> Thanks for looking into this. >> >> Simon Marchi writes: >> >>> On 2023-10-03 15:53, Thiago Jung Bauermann via Gdb-patches wrote: >>>> This fixes "ERROR: internal buffer is full." in gdb.base/maint.exp when >>>> running with "make check-read1". >>>> >>>> Also take the opportunity to fix stray whitespace in the vicinity. >>>> --- >>>> gdb/testsuite/lib/gdb.exp | 9 +++++---- >>>> 1 file changed, 5 insertions(+), 4 deletions(-) >>>> >>>> diff --git a/gdb/testsuite/lib/gdb.exp b/gdb/testsuite/lib/gdb.exp >>>> index de22da8d8a8c..c6ee4628f8f5 100644 >>>> --- a/gdb/testsuite/lib/gdb.exp >>>> +++ b/gdb/testsuite/lib/gdb.exp >>>> @@ -6533,13 +6533,14 @@ proc default_gdb_init { test_file_name } { >>>> if { $gdb_wrapper_target != [current_target_name] } { >>>> set gdb_wrapper_initialized 0 >>>> } >>>> - >>>> + >>>> # Unlike most tests, we have a small number of tests that generate >>>> # a very large amount of output. We therefore increase the expect >>>> # buffer size to be able to contain the entire test output. This >>>> - # is especially needed by gdb.base/info-macros.exp. >>>> - match_max -d 65536 >>>> - # Also set this value for the currently running GDB. >>>> + # is especially needed by gdb.base/info-macros.exp and >>>> + # gdb.base/maint.exp. >>>> + match_max -d 196608 >>>> + # Also set this value for the currently running GDB. >>>> match_max [match_max -d] >>>> >>>> # We want to add the name of the TCL testcase to the PASS/FAIL messages. >>> >>> Do you have details about what fails specifically? It runs fine here, >> >> I think that what causes trouble is the fact that the line tables of the >> dynamic linker are huge. >> >> What happens is that when testing "maint info line-table w/o a file >> name", expect times out in the middle of "maint info line-table" output >> while it's listing the line-table of dl-load.c. A bit after that I get >> the first 2 "ERROR: internal buffer is full." (I get between 2 and 5 >> such ERRORs depending on the machine). >> >> Then there are a few more errors while printing the line table of >> elf/rtld.c. >> >>> so I'm curious which part of the test fills the buffer exactly. Also, >> >> Interesting. This fails on all 4 of the machines I tried, covering >> aarch64-linux, armv8l-linux-gnueabihf and x86_84-linux. Do you have >> libc6 debuginfo installed? > > I do, on my Ubuntu system, but my build wasn't configured to use it. I > added --with-separate-debug-dir=/usr/lib/debug to my build (it defaults > to /usr/local/lib/debug), and now my GDB picks up the debug info for > libc. > > 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. -- Thiago