ping: [patch] [mi] Fix crash on stale frame_info * - PR 11788

[Jan Kratochvil <jan dot kratochvil at redhat dot com>]

ping (a "popular" bug)

On Fri, 06 Aug 2010 16:22:59 +0200, Jan Kratochvil wrote:
Hi,

http://sources.redhat.com/bugzilla/show_bug.cgi?id=11788
backtrace:
https://bugzilla.redhat.com/attachment.cgi?id=429195

sometimes GDB can crash.  I do not have a reproducible crash but at least
valgrind complains:

cat >cmd <<EOH
100-gdb-set height 0
101-gdb-set width 0
105-file-exec-and-symbols gdb.mi/mi-break
-break-insert -i 1 callme
220-exec-run
-var-create W * callme(i)
EOH
valgrind --num-callers=15 ../gdb -nx -i=mi <cmd
[...]
== Invalid read of size 8 
==    at 0x496F4F: get_frame_pc (frame.c:1792)
==    by 0x496FB3: get_frame_address_in_block (frame.c:1802)
==    by 0x496050: select_frame (frame.c:1288)
==    by 0x747806: varobj_create (varobj.c:643)
==    by 0x5FC7DF: mi_cmd_var_create (mi-cmd-var.c:149)
==    by 0x60430D: mi_cmd_execute (mi-main.c:1886)
==    by 0x603A55: captured_mi_execute_command (mi-main.c:1655)
==    by 0x6ABCD2: catch_exception (exceptions.c:468)
==    by 0x603CF0: mi_execute_command (mi-main.c:1751)
==    by 0x5FFAA5: mi_execute_command_wrapper (mi-interp.c:262)
==    by 0x6B4671: gdb_readline2 (event-top.c:783)
==    by 0x6B3DD4: stdin_event_handler (event-top.c:433)
==    by 0x6B24BD: handle_file_event (event-loop.c:817)
==    by 0x6B19B3: process_event (event-loop.c:399)
==    by 0x6B1A59: gdb_do_one_event (event-loop.c:452)
==  Address 0xce64640 is 352 bytes inside a block of size 4,064 free'd 
==    at 0x4C25D72: free (vg_replace_malloc.c:325)
==    by 0x48E331: xfree (utils.c:1467)
==    by 0x65C3AE7: obstack_free (in /lib64/libc-2.12.90.so)
==    by 0x49639B: reinit_frame_cache (frame.c:1384)
==    by 0x64BBF9: regcache_write_pc (regcache.c:959)
==    by 0x6978F9: proceed (infrun.c:1926)
==    by 0x68EECC: run_inferior_call (infcall.c:378)
==    by 0x68FA2B: call_function_by_hand (infcall.c:804)
==    by 0x65B619: evaluate_subexp_standard (eval.c:1794)
==    by 0x73C6D2: evaluate_subexp_c (c-lang.c:1047)
==    by 0x6570D2: evaluate_subexp (eval.c:76)
==    by 0x6572D1: evaluate_expression (eval.c:167)
==    by 0x74D2D1: gdb_evaluate_expression (wrapper.c:48)
==    by 0x74774E: varobj_create (varobj.c:621)
==    by 0x5FC7DF: mi_cmd_var_create (mi-cmd-var.c:149)

No regressions on {x86_64,x86_64-m32,i686}-fedora14snapshot-linux-gnu.

Checked on the testcase above it really (re-)selects the right frame.


Thanks,
Jan


gdb/
2010-08-06  Jan Kratochvil  <jan.kratochvil@redhat.com>

	* varobj.c (varobj_create): Replace variable old_fi with old_id,
	initialize it by null_frame_id, wrap its usage by get_frame_id,
	frame_id_p and frame_find_by_id.

--- gdb/varobj.c	6 Aug 2010 14:17:56 -0000	1.159
+++ gdb/varobj.c	6 Aug 2010 14:19:17 -0000
@@ -537,7 +537,7 @@ varobj_create (char *objname,
   if (expression != NULL)
     {
       struct frame_info *fi;
-      struct frame_info *old_fi = NULL;
+      struct frame_id old_id = null_frame_id;
       struct block *block;
       char *p;
       enum varobj_languages lang;
@@ -611,7 +611,7 @@ varobj_create (char *objname,
 
 	  var->root->frame = get_frame_id (fi);
 	  var->root->thread_id = pid_to_thread_id (inferior_ptid);
-	  old_fi = get_selected_frame (NULL);
+	  old_id = get_frame_id (get_selected_frame (NULL));
 	  select_frame (fi);	 
 	}
 
@@ -639,8 +639,8 @@ varobj_create (char *objname,
       var->root->rootvar = var;
 
       /* Reset the selected frame */
-      if (old_fi != NULL)
-	select_frame (old_fi);
+      if (frame_id_p (old_id))
+	select_frame (frame_find_by_id (old_id));
     }
 
   /* If the variable object name is null, that means this