In gdb -i mi, when creating a variable object, then switching to another frame, and then updating the 
variable, GDB crashes. These are the exact steps leading to the crash:

$ gdb -i mi
2-enable-pretty-printing
3-interpreter-exec console "python import sys; from libstdcxx.v6.printers import 
register_libstdcxx_printers; register_libstdcxx_printers (None)" 
4-file-exec-and-symbols ./testapp1
5-interpreter-exec console "b testapp1.C:26"
8-exec-run
[wait until breakpoint is hit]
12-stack-select-frame 2
14-var-create - @ allResults
16-stack-select-frame 1
17-var-update --all-values "var1"

The testapp1 source code is attached below (build with "g++ -g -O0 -o testapp1 testapp1.C"; I used 
g++ 4.3.3 on Ubuntu 9.04).
allResults is a local variable that exists in frame 2 but not in frame 1.
If pretty-printing is not enabled, the crash does not occur. Similarly, when looking at a global variable  
instead (like someGlobalVar), the crash doesn't occur.

Here is the backtrace from gdb crash:
(gdb) bt
#0  0xb7c3c07a in strcmp () from /lib/tls/i686/cmov/libc.so.6
#1  0x08201972 in install_new_value (var=0x8ac6608, value=0x0, initial=0) at varobj.c:1586
#2  0x08201d28 in varobj_update (varp=0xbf94f0b0, explicit=1) at varobj.c:1713
#3  0x080fb023 in varobj_update_one (var=0x8ac6608, print_values=PRINT_ALL_VALUES, explicit=1) 
at ./mi/mi-cmd-var.c:721
#4  0x080faff7 in mi_cmd_var_update (command=0x8abc828 "var-update", argv=0x8950380, 
argc=2) at ./mi/mi-cmd-var.c:703
#5  0x080ffffd in mi_cmd_execute (parse=0x89f9108) at ./mi/mi-main.c:1388
#6  0x080ff972 in captured_mi_execute_command (uiout=0x89895f0, data=0x89f9108) at ./mi/mi-
main.c:1194
#7  0x081832e2 in catch_exception (uiout=0x89895f0, func=0x80ff8ae 
<captured_mi_execute_command>, func_args=0x89f9108, mask=6) at exceptions.c:462
#8  0x080ffbef in mi_execute_command (cmd=0x8bc8290 "17-var-update --all-values \"var1\"", 
from_tty=1) at ./mi/mi-main.c:1288
#9  0x080fd0bc in mi_execute_command_wrapper (cmd=0x8bc8290 "17-var-update --all-values 
\"var1\"") at ./mi/mi-interp.c:251
#10 0x0818aa81 in gdb_readline2 (client_data=0x0) at event-top.c:817
#11 0x0818a1a6 in stdin_event_handler (error=0, client_data=0x0) at event-top.c:433
#12 0x08188e86 in handle_file_event (data=...) at event-loop.c:812
#13 0x081885cb in process_event () at event-loop.c:394
#14 0x081886a3 in gdb_do_one_event (data=0x0) at event-loop.c:459
#15 0x081834ab in catch_errors (func=0x81885e0 <gdb_do_one_event>, func_args=0x0, 
errstring=0x8365150 "", mask=6) at exceptions.c:510
#16 0x081886e6 in start_event_loop () at event-loop.c:483
#17 0x080fd131 in mi_command_loop (mi_version=2) at ./mi/mi-interp.c:281
#18 0x080fd0e4 in mi2_command_loop () at ./mi/mi-interp.c:263
#19 0x08183a4c in current_interp_command_loop () at interps.c:288
#20 0x0808e950 in captured_command_loop (data=0x0) at ./main.c:226
#21 0x081834ab in catch_errors (func=0x808e945 <captured_command_loop>, func_args=0x0, 
errstring=0x832441f "", mask=6) at exceptions.c:510
#22 0x0808f898 in captured_main (data=0xbf94f4f0) at ./main.c:902
#23 0x081834ab in catch_errors (func=0x808e986 <captured_main>, func_args=0xbf94f4f0, 
errstring=0x832441f "", mask=6) at exceptions.c:510
#24 0x0808f8ce in gdb_main (args=0xbf94f4f0) at ./main.c:911
#25 0x0808e6c7 in main (argc=3, argv=0xbf94f5a4) at gdb.c:33

The problem is reproducable for me.
Any hints at workarounds for GDB 7.0 would be highly appreciated :-)