public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: Simon Marchi <simark@simark.ca>
To: Thiago Jung Bauermann <thiago.bauermann@linaro.org>
Cc: gdb-patches@sourceware.org
Subject: Re: [PATCH] gdb/testsuite: Bump up 'match_max'
Date: Wed, 4 Oct 2023 21:39:24 -0400	[thread overview]
Message-ID: <ad9d9310-d752-477c-a608-4a45015a22b4@simark.ca> (raw)
In-Reply-To: <87ttr6m2j7.fsf@linaro.org>



On 2023-10-04 18:43, Thiago Jung Bauermann wrote:
> 
> Hello Simon,
> 
> Thanks for looking into this.
> 
> Simon Marchi <simark@simark.ca> 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
     }
 }

  reply	other threads:[~2023-10-05  1:39 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-10-03 19:53 Thiago Jung Bauermann
2023-10-04  1:04 ` Simon Marchi
2023-10-04 22:43   ` Thiago Jung Bauermann
2023-10-05  1:39     ` Simon Marchi [this message]
2023-10-05  2:41       ` Thiago Jung Bauermann
2023-10-06 17:01         ` Andrew Burgess
2023-10-06 20:34           ` Thiago Jung Bauermann
2023-10-09  9:49             ` Andrew Burgess
  -- strict thread matches above, loose matches on Subject: below --
2014-05-17 20:57 [PATCH] GDB/testsuite: Bump up `match_max' Maciej W. Rozycki
2014-05-19 14:18 ` Tom Tromey
2014-05-19 14:23   ` Joel Brobecker
2014-05-19 14:37     ` Joel Brobecker
2014-05-19 21:22       ` Doug Evans
2014-05-20  0:47         ` Maciej W. Rozycki
2014-05-20  2:05           ` Joel Brobecker
2014-05-21 19:41             ` Maciej W. Rozycki

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ad9d9310-d752-477c-a608-4a45015a22b4@simark.ca \
    --to=simark@simark.ca \
    --cc=gdb-patches@sourceware.org \
    --cc=thiago.bauermann@linaro.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).