Blame SOURCES/gdb-follow-child-stale-parent.patch

f9426a
Problem occurs with python and its get_current_arch () as it selects
f9426a
selected_frame and current_frame while still inferior_ptid is valid for the
f9426a
original parent.  But since this place it is already attached and later
f9426a
unwinders try to access it, breaking:
f9426a
  -PASS: gdb.threads/watchpoint-fork.exp: child: singlethreaded: breakpoint after the first fork
f9426a
  -PASS: gdb.threads/watchpoint-fork.exp: child: singlethreaded: watchpoint after the first fork
f9426a
  -PASS: gdb.threads/watchpoint-fork.exp: child: singlethreaded: breakpoint after the second fork
f9426a
  -PASS: gdb.threads/watchpoint-fork.exp: child: singlethreaded: watchpoint after the second fork
f9426a
  -PASS: gdb.threads/watchpoint-fork.exp: child: singlethreaded: finish
f9426a
  +FAIL: gdb.threads/watchpoint-fork.exp: child: singlethreaded: breakpoint after the first fork
f9426a
  +FAIL: gdb.threads/watchpoint-fork.exp: child: singlethreaded: watchpoint after the first fork
f9426a
  +FAIL: gdb.threads/watchpoint-fork.exp: child: singlethreaded: breakpoint after the second fork
f9426a
  +FAIL: gdb.threads/watchpoint-fork.exp: child: singlethreaded: watchpoint after the second fork
f9426a
  +FAIL: gdb.threads/watchpoint-fork.exp: child: singlethreaded: finish
f9426a
f9426a
--- ./gdb/infrun.c	2009-12-21 20:26:30.000000000 +0100
f9426a
+++ ./gdb/infrun.c	2009-12-21 20:26:11.000000000 +0100
f9426a
@@ -375,6 +375,9 @@ follow_fork (void)
f9426a
 	  }
f9426a
 	else
f9426a
 	  {
f9426a
+	    /* Possibly referenced PARENT is no longer valid.  */
f9426a
+	    reinit_frame_cache ();
f9426a
+
f9426a
 	    /* This pending follow fork event is now handled, one way
f9426a
 	       or another.  The previous selected thread may be gone
f9426a
 	       from the lists by now, but if it is still around, need