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

[Andrew Cagney <ac131313@ges.redhat.com>]

> 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
> 
>