From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca (simark.ca [158.69.221.121]) by sourceware.org (Postfix) with ESMTPS id 794173858D3C for ; Thu, 5 Oct 2023 01:39:25 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 794173858D3C Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=simark.ca Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=simark.ca DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simark.ca; s=mail; t=1696469964; bh=IszO3WK3DsrzRFAYWCv5h3jbpnpNKY8rEMYPfI2Oiv0=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=kul6YmYoSe6YRrsKW5r4cLfBg7QDqpeA9WvNTlVuTkE3BHBtcs0GLFpXDLTchGcAJ qsHG7OpEHPWeGDetz36/mDAtaLgEqTZoc54Mfs+PF+KntB/2x6JMKzEuQtLXuDoeOD 23GvwCLuePluxEr98rXmpmHkXtSp+NbEIZz7OZhc= Received: from [10.0.0.11] (modemcable238.237-201-24.mc.videotron.ca [24.201.237.238]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id 8C02E1E092; Wed, 4 Oct 2023 21:39:24 -0400 (EDT) Message-ID: Date: Wed, 4 Oct 2023 21:39:24 -0400 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] gdb/testsuite: Bump up 'match_max' Content-Language: en-US To: Thiago Jung Bauermann Cc: gdb-patches@sourceware.org References: <20231003195338.334948-1-thiago.bauermann@linaro.org> <87ttr6m2j7.fsf@linaro.org> From: Simon Marchi In-Reply-To: <87ttr6m2j7.fsf@linaro.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-10.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,GIT_PATCH_0,SPF_HELO_PASS,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: 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. Simon diff --git a/gdb/testsuite/gdb.base/maint.exp b/gdb/testsuite/gdb.base/maint.exp index c05d0987e7f..99574f59c44 100644 --- a/gdb/testsuite/gdb.base/maint.exp +++ b/gdb/testsuite/gdb.base/maint.exp @@ -388,14 +388,17 @@ 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\]*" { set saw_srcfile 1 + puts ">>> header a: $expect_out(0,string)" 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\]*" { # Match each symtab to avoid overflowing expect's buffer. + puts ">>> header b: '$expect_out(0,string)'" exp_continue } -re "symtab: \[^\n\r\]+ \\(\\(struct symtab \\*\\) $hex\\)\r\nlinetable: \\(\\(struct linetable \\*\\) 0x0\\):\r\nNo line table.\r\n" { # For symtabs with no linetable. + puts ">>> header no lt: '$expect_out(0,string)'" exp_continue } -re "^$decimal\[ \t\]+$decimal\[ \t\]+$hex\[ \t\]+$hex\[^\r\n\]*\r\n" { @@ -414,17 +417,21 @@ gdb_test_multiple "maint info line-table" \ # 455 END 0x00007ffff7df1d3f # # Match each line to avoid overflowing expect's buffer. + puts ">>> match line: '$expect_out(0,string)'" exp_continue } -re "^$decimal\[ \t\]+END\[ \t\]+$hex\[ \t\]+$hex\[^\r\n\]*\r\n" { # Matches an end marker in the above. + puts ">>> match end: '$expect_out(0,string)'" exp_continue } -re "^\r\n" { # Empty line between tables. + puts ">>> match empty: '$expect_out(0,string)'" exp_continue } -re "^$gdb_prompt $" { + puts ">>> fini: '$expect_out(0,string)'" gdb_assert $saw_srcfile $gdb_test_name } }