Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Michael Snyder <msnyder@vmware.com>
To: Pedro Alves <pedro@codesourcery.com>
Cc: "gdb-patches@sourceware.org" <gdb-patches@sourceware.org>
Subject: Re: Fix foll-fork.exp foll-vfork.exp fork-child-threads.exp
Date: Mon, 01 Dec 2008 19:01:00 -0000	[thread overview]
Message-ID: <493433D7.7080803@vmware.com> (raw)
In-Reply-To: <200811201328.13651.pedro@codesourcery.com>

Pedro Alves wrote:
> Long story short:
> 
> After following a child, detaching from the parent,
> 
> ('set follow-fork-mode child' + 'set detach-on-fork on')
> 
> here in this bit,
> 
>  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.
> 
> With some local changes I was making, sometimes, `tp' happened to be left pointing
> at linux_nat.c:lwp_list, and so that assignment above ended up clearing
> lp->waitstatus.kind (of the first lwp in the list), which resulted in
> GDB considering that the child process had
> exited (because TARGET_SIGNAL_0 == TARGET_WAITKIND_EXITED).
> 
> This should fix intermittent foll-fork.exp foll-vfork.exp
> fork-child-threads.exp failures.
> 
> Checked in.

Pedro,

I'm not sure if this change goes far enough.
If a multi-threaded program forks, only the currently
executing thread survives in the child.  All others are
left behind (and its not unlikely that the thread library
is left in an inconsistant state, possibly leading to
deadlocks).

We can't do anything about that, but we could, eg.,
invalidate all known debugger state having to do with
other threads.  Clear the gdb thread list and preserve
only the current thread.

What do you think?




> ------------------------------------------------------------------------
> 
> 2008-11-20  Pedro Alves  <pedro@codesourcery.com>
> 
> 	* infrun.c (resume): If following a fork, reread the current
> 	thread.  Avoid dereferencing a possibly dangling pointer.
> 
> ---
>  gdb/infrun.c |    7 +++++--
>  1 file changed, 5 insertions(+), 2 deletions(-)
> 
> Index: src/gdb/infrun.c
> ===================================================================
> --- src.orig/gdb/infrun.c	2008-11-20 05:37:35.000000000 +0000
> +++ src/gdb/infrun.c	2008-11-20 12:30:26.000000000 +0000
> @@ -1053,6 +1053,9 @@ a command like `return' or `jump' to con
>        pending_follow.kind = TARGET_WAITKIND_SPURIOUS;
>        if (follow_fork ())
>  	should_resume = 0;
> +
> +      /* Following a fork may change inferior_ptid.  */
> +      tp = inferior_thread ();
>        break;
>  
>      case TARGET_WAITKIND_EXECD:
> @@ -1148,11 +1151,11 @@ a command like `return' or `jump' to con
>            displaced_step_dump_bytes (gdb_stdlog, buf, sizeof (buf));
>          }
>  
> -      target_resume (resume_ptid, step, sig);
> -
>        /* Avoid confusing the next resume, if the next stop/resume
>  	 happens to apply to another thread.  */
>        tp->stop_signal = TARGET_SIGNAL_0;
> +
> +      target_resume (resume_ptid, step, sig);
>      }
>  
>    discard_cleanups (old_cleanups);


  parent reply	other threads:[~2008-12-01 19:01 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-11-20 19:15 Pedro Alves
2008-11-20 23:52 ` Ulrich Weigand
2008-11-21  1:35   ` Pedro Alves
2008-11-21  1:49     ` Ulrich Weigand
2008-11-21  2:09       ` Pedro Alves
2008-11-21 11:40         ` Ulrich Weigand
2008-11-21 12:58           ` Pedro Alves
2008-12-01 19:01 ` Michael Snyder [this message]
2008-12-01 20:56   ` Daniel Jacobowitz
2008-12-01 22:36     ` Michael Snyder
2008-12-01 21:06   ` Pedro Alves
2008-12-01 22:38     ` Michael Snyder

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=493433D7.7080803@vmware.com \
    --to=msnyder@vmware.com \
    --cc=gdb-patches@sourceware.org \
    --cc=pedro@codesourcery.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox