MI problem

MI problem

[Andrew STUBBS]

Hi all,

When I run GDB with -i=mi1 I get a segmentation fault while running the 
'load' command. (-i=mi2 works fine.)

The fault occurs in ui_file_put() due to 'file' having no useful value. 
This value is taken from uiout.data->buffer (MI version of data).

I have traced the 'source' of this rogue data to cli_interpreter_exec() 
which passes cli_uiout to safe_execute_command() which calls 
exceptions_state_mc_init() which changes the global uiout.

The MI seems to be calling the CLI to interpret the 'load' command, but 
the CLI then clashes with the MI I/O routines causing the fault, in this 
case under generic_load().

Here is a backtrace from where the uiout gets switched:

#0  exceptions_state_mc_init (func_uiout=0x94034f8, exception=0xbfff93c0,
     mask=155202808) at ../../src/gdb/exceptions.c:102
#1  0x080da1f8 in catch_exception (uiout=0x93f9b90,
     func=0x8085dac <do_captured_execute_command>, func_args=0xbfff9418, 
mask=6)
     at ../../src/gdb/exceptions.c:467
#2  0x08085df1 in safe_execute_command (uiout=0x93f9b90,
     command=0x94034f8 "\002", from_tty=155202808)
     at ../../src/gdb/cli/cli-interp.c:132
#3  0x08085d7e in cli_interpreter_exec (data=0x0, command_str=0x83f8a40 "")
     at ../../src/gdb/cli/cli-interp.c:112
#4  0x080da86a in interp_exec (interp=0x83f8a40, command_str=0x9403380 
"load")
     at ../../src/gdb/interps.c:313
#5  0x08088cfd in mi_cmd_interpreter_exec (
     command=0x8314ac4 "-interpreter-exec", argv=0xbfff9520, argc=2)
     at ../../src/gdb/mi/mi-interp.c:242
#6  0x0808a393 in captured_mi_execute_command (uiout=0x93fa180,
     data=0xbfff95b0) at ../../src/gdb/mi/mi-main.c:1110
#7  0x080da226 in catch_exception (uiout=0x93fa180,
     func=0x808a338 <captured_mi_execute_command>, func_args=0xbfff95b0, 
mask=6)
     at ../../src/gdb/exceptions.c:469
#8  0x0808a5e0 in mi_execute_command (cmd=0x947e7f0 "\001", from_tty=1)
     at ../../src/gdb/mi/mi-main.c:1157
#9  0x08088e60 in mi_execute_command_wrapper (cmd=0x94c21d0 "load")
     at ../../src/gdb/mi/mi-interp.c:300
#10 0x080de108 in gdb_readline2 (client_data=0x0)
     at ../../src/gdb/event-top.c:873
#11 0x080dd7ee in stdin_event_handler (error=0, client_data=0x94034f8)
     at ../../src/gdb/event-top.c:424
#12 0x080dcb54 in handle_file_event (event_file_desc=138381888)
     at ../../src/gdb/event-loop.c:728
#13 0x080dc698 in process_event () at ../../src/gdb/event-loop.c:341
#14 0x080dc6e0 in gdb_do_one_event (data=0x0) at 
../../src/gdb/event-loop.c:378
#15 0x080da3af in catch_errors (func=0x80dc6b0 <gdb_do_one_event>,
     func_args=0x0, errstring=0x8307576 "", mask=6)
     at ../../src/gdb/exceptions.c:515
#16 0x080dc703 in start_event_loop () at ../../src/gdb/event-loop.c:404
#17 0x08088e71 in mi1_command_loop () at ../../src/gdb/mi/mi-interp.c:306
#18 0x080da7e2 in current_interp_command_loop () at 
../../src/gdb/interps.c:275
#19 0x08050cdb in captured_command_loop (data=0x0) at 
../../src/gdb/main.c:101
#20 0x080da3af in catch_errors (func=0x8050cd0 <captured_command_loop>,
     func_args=0x0, errstring=0x8307576 "", mask=6)
     at ../../src/gdb/exceptions.c:515
#21 0x08051882 in captured_main (data=0x1) at ../../src/gdb/main.c:839
#22 0x080da3af in catch_errors (func=0x8050d08 <captured_main>,
     func_args=0xbfff9940, errstring=0x8307576 "", mask=6)
     at ../../src/gdb/exceptions.c:515
#23 0x080519d3 in gdb_main (args=0x83f8a40) at ../../src/gdb/main.c:848
#24 0x08050ccb in main (argc=155202808, argv=0x94034f8)
     at ../../src/gdb/gdb.c:35

The GDB simulator does not use generic_load() so that works fine, but as 
far as I can tell it should be possible to reproduce the problem using 
'target remote'. However, I have no suitable targets with which to test 
this. I am using generic_load() from a custom target interface, but I do 
not think this is causing the problem. It worked fine for GDB 6.3. Could 
somebody with a 'remote' target please try to reproduce it?

I'm really not sure where the problem actually is. I don't think it is 
related to generic_load() per se. That just happens to be where I see 
the problem. Is it the CLI that is wrong, or the MI or even the 
exception handling stuff?

BTW, The three versions of 'struct ui_out_data' are very confusing. 
There is no way (I can see) to get GDB (when being used to debug GDB) to 
print the right one anywhere other than the specific file in which it is 
defined. Everywhere else it just selects one hopes it is right. It would 
be better if they were named differently and then typedefed to the same 
- then one could cast to the right thing and print them properly. Of 
course a union would be even less confusing ...

Thanks, any help appreciated. If I sound confused it is because I am :(

Re: MI problem

[Daniel Jacobowitz]

On Mon, Nov 14, 2005 at 06:55:48PM +0000, Andrew STUBBS wrote:
> Hi all,
> 
> When I run GDB with -i=mi1 I get a segmentation fault while running the 
> 'load' command. (-i=mi2 works fine.)
> 
> The fault occurs in ui_file_put() due to 'file' having no useful value. 
> This value is taken from uiout.data->buffer (MI version of data).
> 
> I have traced the 'source' of this rogue data to cli_interpreter_exec() 
> which passes cli_uiout to safe_execute_command() which calls 
> exceptions_state_mc_init() which changes the global uiout.
> 
> The MI seems to be calling the CLI to interpret the 'load' command, but 
> the CLI then clashes with the MI I/O routines causing the fault, in this 
> case under generic_load().
> 
> Here is a backtrace from where the uiout gets switched:

The interesting question isn't where it gets switched, but where we're
expecting the wrong contents.  If we're accessing uiout.data->buffer
then we must have reached mi_out_put.  So where from, and how did we
get there without switching the global uiout back to MI's? 
mi_cmd_interpreter_exec ought to be doing that on the way out.


-- 
Daniel Jacobowitz
CodeSourcery, LLC