Re: [PATCH] gdb/testsuite: Bump up 'match_max'

[Andrew Burgess <aburgess@redhat.com>]

Thiago Jung Bauermann <thiago.bauermann@linaro.org> writes:

> Hello Andrew,
>
> Andrew Burgess <aburgess@redhat.com> writes:
>
>> Thiago Jung Bauermann via Gdb-patches <gdb-patches@sourceware.org>
>> writes:
>>
>>> Simon Marchi <simark@simark.ca> writes:
>>>
>>>> On 2023-10-04 18:43, Thiago Jung Bauermann wrote:
>>>>> 
>>>>> Hello Simon,
>>>>> 
>>>>> Thanks for looking into this.
>>>>> 
>>>>> Simon Marchi <simark@simark.ca> 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.bauermann@linaro.org>

Thanks.  Pushed the patch below.

Thanks,
Andrew

---

commit 2f349e7d2ac51d29994db57498accd38f893f200
Author: Andrew Burgess <aburgess@redhat.com>
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 <thiago.bauermann@linaro.org>

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
     }