[RFA/testsuite] Increase expect buffer size (related to GPLv3)

[RFA/testsuite] Increase expect buffer size (related to GPLv3)

[Joel Brobecker]

[-- Attachment #1: Type: text/plain, Size: 898 bytes --]

Hello,

After switching "info copying/warranty" to GPLv3, the testsuite showed
one regression (expected), and two ERRORs because of expect buffer
overflow. The overflow comes from the fact that the GPLv3 terms are
much longer than the terms in GPLv2.

I think the attached patch is the appropriate change, but perhaps
there is a way to change the buffer size locally for the test or
the testcase, instead of expanding it globally for all testcases.
I really don't think that growing the buffer to 30kb (from 20kb)
is a big deal, but perhaps it has some effects that I haven't noticed
(like performance hits)... Hence the RFA rather than committing it
using the obvious rule.

2007-08-23  Joel Brobecker  <brobecker@adacore.com>

        * lib/gdb.exp (default_gdb_init): Increase expect buffer size
        to 30000 (from 20000).

Tested on x86-linux. No regression.
OK to apply?

Thanks,
-- 
Joel

[-- Attachment #2: lib-gdb.diff --]
[-- Type: text/plain, Size: 945 bytes --]

Index: lib/gdb.exp
===================================================================
RCS file: /cvs/src/src/gdb/testsuite/lib/gdb.exp,v
retrieving revision 1.85
diff -u -p -r1.85 gdb.exp
--- lib/gdb.exp	23 Aug 2007 18:14:19 -0000	1.85
+++ lib/gdb.exp	23 Aug 2007 19:51:59 -0000
@@ -2085,9 +2085,10 @@ proc default_gdb_init { args } {
     # with the appropriate multilib option.
     set gdb_wrapper_initialized 0
     
-    # Uh, this is lame. Really, really, really lame. But there's this *one*
-    # testcase that will fail in random places if we don't increase this.
-    match_max -d 20000
+    # 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.
+    match_max -d 30000
 
     # We want to add the name of the TCL testcase to the PASS/FAIL messages.
     if { [llength $args] > 0 } {

Re: [RFA/testsuite] Increase expect buffer size (related to GPLv3)

[Daniel Jacobowitz]

On Thu, Aug 23, 2007 at 03:56:24PM -0400, Joel Brobecker wrote:
> Hello,
> 
> After switching "info copying/warranty" to GPLv3, the testsuite showed
> one regression (expected), and two ERRORs because of expect buffer
> overflow. The overflow comes from the fact that the GPLv3 terms are
> much longer than the terms in GPLv2.
> 
> I think the attached patch is the appropriate change, but perhaps
> there is a way to change the buffer size locally for the test or
> the testcase, instead of expanding it globally for all testcases.
> I really don't think that growing the buffer to 30kb (from 20kb)
> is a big deal, but perhaps it has some effects that I haven't noticed
> (like performance hits)... Hence the RFA rather than committing it
> using the obvious rule.
> 
> 2007-08-23  Joel Brobecker  <brobecker@adacore.com>
> 
>         * lib/gdb.exp (default_gdb_init): Increase expect buffer size
>         to 30000 (from 20000).
> 
> Tested on x86-linux. No regression.
> OK to apply?

This is fine.  It is also possible to do locally; instead of a single
gdb_test, use gdb_test_multiple and match other lines of text using
"exp_continue" to keep looking for the prompt.  There's some examples
of this already.  But bumping up the limit to a nice bounded value is
fine too.

-- 
Daniel Jacobowitz
CodeSourcery

Re: [RFA/testsuite] Increase expect buffer size (related to GPLv3)

[Joel Brobecker]

> > 2007-08-23  Joel Brobecker  <brobecker@adacore.com>
> > 
> >         * lib/gdb.exp (default_gdb_init): Increase expect buffer size
> >         to 30000 (from 20000).
> > 
> > Tested on x86-linux. No regression.
> > OK to apply?
> 
> This is fine.

Thanks! I checked this in.

> It is also possible to do locally; instead of a single gdb_test, use
> gdb_test_multiple and match other lines of text using "exp_continue"
> to keep looking for the prompt.  There's some examples of this
> already.

Aha, thanks for the tip!

-- 
Joel