Daniel Jacobowitz wrote: > 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. This is the backtrace from the core dump file: #0 0x0805a220 in ui_file_put (file=0x19, write=0x80863f8 , dest=0xa030f18) at ../../src/gdb/ui-file.c:192 #1 0x0808642a in mi_out_put (uiout=0xa028b90, stream=0xa030f18) at ../../src/gdb/mi/mi-out.c:376 #2 0x0808adc9 in mi_load_progress (section_name=0xa11f79f ".init", sent_so_far=54, total_section=54, total_sent=54, grand_total=523177) at ../../src/gdb/mi/mi-main.c:1402 #3 0x080c4857 in load_section_callback (abfd=0xa0a5278, asec=0x36, data=0xbfffb930) at ../../src/gdb/symfile.c:1597 #4 0x0818c69d in bfd_map_over_sections (abfd=0xa0a5278, operation=0x80c4670 , user_storage=0xbfffb930) at ../../src/bfd/section.c:1226 #5 0x080c4a17 in generic_load (args=0xbfffb930 "", from_tty=1) at ../../src/gdb/symfile.c:1670 #6 0x080edf1f in target_load (arg=0xa0322b0 "/home/afra/users/stubbsa/os21test-microdev", from_tty=1) at ../../src/gdb/target.c:268 mi_load_progress is actually called through the function pointer deprecated_show_load_progress. The problem appears to be that the program is finding it's way into the MI through deprecated_show_load_progress when uiout is not set as expected. The problem only occurs in -i=mi (no number) and -i=mi1 because mi_load_progress does not do anything in other versions. Strangely -i=mi is supposed to be the same as -i=mi2, but it isn't in this respect. I attach a patch which fixes both the crash and the inconsistency. I have tested it and got no unexpected failures. Of course I doubt the testsuite covers this feature ... OK? I would like to see this issued fixed in 6.4 also. Andrew Stubbs