This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]