[RFA/MI testsuite] check for known uiout bugs

[RFA/MI testsuite] check for known uiout bugs

[Keith Seitz]

Hi,

This patch adds a test to mi-basics.exp which tests the following uiout 
bug:

$ ./gdb -i=mi -nw -nx -q
(gdb)
-data-list-register-names -1
^error,msg="bad register number"
(gdb)
-data-list-register-names -1
^error,msg="bad register number"
(gdb)
-data-list-register-names -1
^error,msg="bad register number"
(gdb)
-data-list-register-names -1
^error,msg="bad register number"
(gdb)
-data-list-register-names -1
&"../../src/gdb/ui-out.c:130: gdb-internal-error: push_level: Assertion 
`uiout->level>= 0 && uiout->level < MAX_UI_OUT_LEVELS' failed.\n"
~"An internal GDB error was detected.  This may make further\n"
~"debugging unreliable.  Quit this debugging session? (y or n) "

This happens because the register-handling code does stuff like (pardon 
pseudo-code):

   ui_out_list_begin (...);
   foreach register requested
    {
       if register number is invalid
          return MI_CMD_ERROR
       ui_out_field_string (uiout, "name", REGISTER_NAME (register));
    }

    ui_out_list_end (uiout);
    return MI_CMD_DONE;

In other words, when an MI error occurs (one that doesn't occur via 
error()), the uiout still thinks that it is building a list. It fails to 
reset the uiout to some starting state with uiout->level = 0.

Keith

ChangeLog
2002-08-30  Keith Seitz  <keiths@redhat.com>

        * mi-basics.exp (test_generic_problems): New procedure.
        Add test to check for uiout list/tuple nesting bug.

Patch
Index: testsuite/gdb.mi/mi-basics.exp
===================================================================
RCS file: /cvs/src/src/gdb/testsuite/gdb.mi/mi-basics.exp,v
retrieving revision 1.6
diff -p -r1.6 mi-basics.exp
*** testsuite/gdb.mi/mi-basics.exp	27 Jun 2001 17:27:07 -0000	1.6
--- testsuite/gdb.mi/mi-basics.exp	30 Aug 2002 21:14:45 -0000
*************** proc test_dir_specification {} {
*** 164,173 ****
--- 164,195 ----
  #exp_internal 0
  }
  
+ proc test_generic_problems {} {
+ 
+   # Tests a bug with ui-out and nested uiout types. When 
+   # an error is encountered building a nest typed, like
+   # lists or tuples, the uiout is not reset to some sane
+   # state. As a result, uiout still thinks it is building
+   # this nested type. Execute enough of these errors and
+   # an assertion failure occurs. This is most obvious
+   # with invalid register number and the register commands.
+   #
+   # It should be sufficient to test call -data-list-register-names
+   # at least MAX_UIOUT_LEVELS + 1 times. We just assume a really
+   # high MAX_UIOUT_LEVELS to do this.
+   set counter 0
+   for {set i 0} {$i < 20} {incr i} {
+     mi_gdb_test "[expr {200 + $counter}]-data-list-register-names -1" \
+       {.*^error,msg="bad register number"} \
+       "[expr {200 + $counter}]-data-list-register-names -1"
+   }
+ }
+ 
  if [test_mi_interpreter_selection] {
    test_exec_and_symbol_mi_operatons
    test_breakpoints_deletion
    test_dir_specification
+   test_generic_problems
  }
  
  mi_gdb_exit

Re: [RFA/MI testsuite] check for known uiout bugs

[Andrew Cagney]

> Hi,
> 
> This patch adds a test to mi-basics.exp which tests the following uiout 
> bug:

I don't think this belongs in mi-basics.exp.

Assuming Fernando is ok with this (it means adopting a new testsuite 
convention), I think put it in a new file:

	gdb/testsuite/gdb.mi/gdb<bugid>.exp
or
	gdb/testsuite/gdb.mi/<bugid>.exp
or
	gdb/testsuite/gdb.mi/mi-<bugid>.exp

(I suspect gdb<bugid> is safest :-).  Given that it is going to fail the 
test will need to be able to identify the exact point where the failure 
is expected so that it can be marked with a ``setup_kfail''.

Andrew



> $ ./gdb -i=mi -nw -nx -q
> (gdb)
> -data-list-register-names -1
> ^error,msg="bad register number"
> (gdb)
> -data-list-register-names -1
> ^error,msg="bad register number"
> (gdb)
> -data-list-register-names -1
> ^error,msg="bad register number"
> (gdb)
> -data-list-register-names -1
> ^error,msg="bad register number"
> (gdb)
> -data-list-register-names -1
> &"../../src/gdb/ui-out.c:130: gdb-internal-error: push_level: Assertion 
> `uiout->level>= 0 && uiout->level < MAX_UI_OUT_LEVELS' failed.\n"
> ~"An internal GDB error was detected.  This may make further\n"
> ~"debugging unreliable.  Quit this debugging session? (y or n) "
> 
> This happens because the register-handling code does stuff like (pardon 
> pseudo-code):
> 
>    ui_out_list_begin (...);
>    foreach register requested
>     {
>        if register number is invalid
>           return MI_CMD_ERROR
>        ui_out_field_string (uiout, "name", REGISTER_NAME (register));
>     }
> 
>     ui_out_list_end (uiout);
>     return MI_CMD_DONE;
> 
> In other words, when an MI error occurs (one that doesn't occur via 
> error()), the uiout still thinks that it is building a list. It fails to 
> reset the uiout to some starting state with uiout->level = 0.
> 
> Keith
> 
> ChangeLog
> 2002-08-30  Keith Seitz  <keiths@redhat.com>
> 
>         * mi-basics.exp (test_generic_problems): New procedure.
>         Add test to check for uiout list/tuple nesting bug.
> 
> Patch
> Index: testsuite/gdb.mi/mi-basics.exp
> ===================================================================
> RCS file: /cvs/src/src/gdb/testsuite/gdb.mi/mi-basics.exp,v
> retrieving revision 1.6
> diff -p -r1.6 mi-basics.exp
> *** testsuite/gdb.mi/mi-basics.exp	27 Jun 2001 17:27:07 -0000	1.6
> --- testsuite/gdb.mi/mi-basics.exp	30 Aug 2002 21:14:45 -0000
> *************** proc test_dir_specification {} {
> *** 164,173 ****
> --- 164,195 ----
>   #exp_internal 0
>   }
>   
> + proc test_generic_problems {} {
> + 
> +   # Tests a bug with ui-out and nested uiout types. When 
> +   # an error is encountered building a nest typed, like
> +   # lists or tuples, the uiout is not reset to some sane
> +   # state. As a result, uiout still thinks it is building
> +   # this nested type. Execute enough of these errors and
> +   # an assertion failure occurs. This is most obvious
> +   # with invalid register number and the register commands.
> +   #
> +   # It should be sufficient to test call -data-list-register-names
> +   # at least MAX_UIOUT_LEVELS + 1 times. We just assume a really
> +   # high MAX_UIOUT_LEVELS to do this.
> +   set counter 0
> +   for {set i 0} {$i < 20} {incr i} {
> +     mi_gdb_test "[expr {200 + $counter}]-data-list-register-names -1" \
> +       {.*^error,msg="bad register number"} \
> +       "[expr {200 + $counter}]-data-list-register-names -1"
> +   }
> + }
> + 
>   if [test_mi_interpreter_selection] {
>     test_exec_and_symbol_mi_operatons
>     test_breakpoints_deletion
>     test_dir_specification
> +   test_generic_problems
>   }
>   
>   mi_gdb_exit
> 
> 

Re: [RFA/MI testsuite] check for known uiout bugs

[Keith Seitz]

On Fri, 30 Aug 2002, Andrew Cagney wrote:

> I don't think this belongs in mi-basics.exp.

I don't really, either, but I knew someone would offer a better place! ;-)

> (I suspect gdb<bugid> is safest :-). 

Will do.

> Given that it is going to fail the test will need to be able to identify 
> the exact point where the failure  is expected so that it can be marked 
> with a ``setup_kfail''.

Okay.
 
BTW, how would people prefer to see this solved? Right now, as far as I 
can tell, this only happens in the register functions. I could simply add 
a call to ui_out_list_end before we return MI_CMD_ERROR, but that seems 
chintzy.

IMO a better approach might be to add a function to ui-out.c to reset this 
uiout and have captured_mi_execute_command call this reset function on the 
uiout when MI_CMD_ERROR is encountered. (Or maybe just add something to 
mi_out_rewind?)

What do you think?
Keith

Re: [RFA/MI testsuite] check for known uiout bugs

[Keith Seitz]

On Fri, 30 Aug 2002, Andrew Cagney wrote:

> (I suspect gdb<bugid> is safest :-).  Given that it is going to fail the 
> test will need to be able to identify the exact point where the failure 
> is expected so that it can be marked with a ``setup_kfail''.

How about the below?
Keith

PS. setup_kfail available? All the references in testsuite were commented 
out. I've followed them.

ChangeLog
2002-08-30  Keith Seitz  <keiths@redhat.com>

        * gdb680.exp: New file to test to check for uiout list/tuple
        nesting bug.

"Patch"
# Copyright 2002 Free Software Foundation, Inc.

# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation; either version 2 of the License, or
# (at your option) any later version.
# 
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
# GNU General Public License for more details.
# 
# You should have received a copy of the GNU General Public License
# along with this program; if not, write to the Free Software
# Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.  

# Please email any bugs, comments, and/or additions to this file to:
# bug-gdb@prep.ai.mit.edu

#
# test gdb/680
#

load_lib mi-support.exp
set MIFLAGS "-i=mi"

gdb_exit
if [mi_gdb_start] {
    continue
}

proc do_test {} {
  mi_gdb_test "-data-list-register-names -1" \
    {\^error,msg=\"bad register number\"} \
    "-data-list-register-names -1"
}

# Tests a bug with ui-out and nested uiout types. When 
# an error is encountered building a nest typed, like
# lists or tuples, the uiout is not reset to some sane
# state. As a result, uiout still thinks it is building
# this nested type. Execute enough of these errors and
# an assertion failure occurs. This is most obvious
# with invalid register number and the register commands.

# MAX_UIOUT_LEVELS is set to 5.
set counter 0
for {set i 0} {$i < 4} {incr i} {
  do_test
}

#setup_kfail "gdb/680"
do_test

mi_gdb_exit
return 0

Re: [RFA/MI testsuite] check for known uiout bugs

[Andrew Cagney]

> On Fri, 30 Aug 2002, Andrew Cagney wrote:
> 
> 
>> (I suspect gdb<bugid> is safest :-).  Given that it is going to fail the 
>> test will need to be able to identify the exact point where the failure 
>> is expected so that it can be marked with a ``setup_kfail''.
> 
> 
> How about the below?

See below.

> PS. setup_kfail available? All the references in testsuite were commented 
> out. I've followed them.

Yes.  The patch needs some doco adjustment before going into the master 
sources.

> ChangeLog
> 2002-08-30  Keith Seitz  <keiths@redhat.com>
> 
>         * gdb680.exp: New file to test to check for uiout list/tuple
>         nesting bug.
> 
> "Patch"

This just needs a tweak so that each time it is run it outputs a unique 
test name, something like ``..register-names -1, try N''.  Otherwize, 
yes, ok.

Andrew


> proc do_test {} {
>   mi_gdb_test "-data-list-register-names -1" \
>     {\^error,msg=\"bad register number\"} \
>     "-data-list-register-names -1"
> }
> 
> # Tests a bug with ui-out and nested uiout types. When 
> # an error is encountered building a nest typed, like
> # lists or tuples, the uiout is not reset to some sane
> # state. As a result, uiout still thinks it is building
> # this nested type. Execute enough of these errors and
> # an assertion failure occurs. This is most obvious
> # with invalid register number and the register commands.
> 
> # MAX_UIOUT_LEVELS is set to 5.
> set counter 0
> for {set i 0} {$i < 4} {incr i} {
>   do_test
> }
> 
> #setup_kfail "gdb/680"
> do_test
> 
> mi_gdb_exit
> return 0
> 
> 

Re: [RFA/MI testsuite] check for known uiout bugs

[Keith Seitz]

On Mon, 2 Sep 2002, Andrew Cagney wrote:

> This just needs a tweak so that each time it is run it outputs a unique 
> test name, something like ``..register-names -1, try N''.  Otherwize, 
> yes, ok.

Doh! I had that originally and then whacked it when I massaged the test 
into a procedure.

I've added it back again and committed it.

Thanks,
Keith