This is the mail archive of the
mailing list for the GDB project.
Re: Fix foll-fork.exp foll-vfork.exp fork-child-threads.exp
- From: "Ulrich Weigand" <uweigand at de dot ibm dot com>
- To: pedro at codesourcery dot com (Pedro Alves)
- Cc: gdb-patches at sourceware dot org
- Date: Thu, 20 Nov 2008 15:28:24 +0100 (CET)
- Subject: Re: Fix foll-fork.exp foll-vfork.exp fork-child-threads.exp
Pedro Alves wrote:
> 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 ();
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.
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE