Re: Fix foll-fork.exp foll-vfork.exp fork-child-threads.exp

["Ulrich Weigand" <uweigand@de.ibm.com>]

Pedro Alves wrote:

>  infrun.c:resume():
>   {
>     ....
>     follow_fork ();
>     ...
>     tp->stop_signal = TARGET_SIGNAL_0;
>   }
> 
> ... `tp' is no longer in the thread list (it was pointing at a thread
> of the parent process, which we've detached from, hence no longer
> in the thread list), so if the assignment above doesn't crash, it ends
> up writing to who-knows-where.

Funny, I was debugging the very same problem just yesterday ...
In my case, the wild store clobbered a struct breakpoint for the
thread event breakpoint.

>        pending_follow.kind = TARGET_WAITKIND_SPURIOUS;
>        if (follow_fork ())
>  	should_resume = 0;
> +
> +      /* Following a fork may change inferior_ptid.  */
> +      tp = inferior_thread ();
>        break;

I guess the "regcache" and "gdbarch" variables now also contain stale
information.  That's not an actual problem right now, as regcache is
(currently) not used after this point, and gdbarch (today) will never
actually change -- but in order to reduce potential future problems,
I think those should also be reset.

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  Ulrich.Weigand@de.ibm.com