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: Should this be on the blocker list for the 7.10 release?


On 15-07-07 03:20 PM, Pedro Alves wrote:
> This one (on top of the other) fixes this for me.  No
> testsuite regressions on x86_64 F20.
> 
> -----
> From 1290101d792c0e1d8c4e202cd7d900837db0ee84 Mon Sep 17 00:00:00 2001
> From: Pedro Alves <palves@redhat.com>
> Date: Tue, 7 Jul 2015 19:50:38 +0100
> Subject: [PATCH] missing exit event
> 
> ---
>  gdb/linux-nat.c | 14 ++++++++++++++
>  1 file changed, 14 insertions(+)
> 
> diff --git a/gdb/linux-nat.c b/gdb/linux-nat.c
> index ea38ebb..281a270 100644
> --- a/gdb/linux-nat.c
> +++ b/gdb/linux-nat.c
> @@ -2275,6 +2275,20 @@ wait_lwp (struct lwp_info *lp)
>        /* Check if the thread has exited.  */
>        if (WIFEXITED (status) || WIFSIGNALED (status))
>  	{
> +	  if (ptid_get_pid (lp->ptid) == ptid_get_lwp (lp->ptid))
> +	    {
> +	      if (debug_linux_nat)
> +		fprintf_unfiltered (gdb_stdlog, "WL: Process %d exited.\n",
> +				    ptid_get_pid (lp->ptid));
> +
> +	      /* This is the leader exiting, it means the whole
> +		 process is gone.  Store the status to report to the
> +		 core.  Store it in the lp->waitstatus, because
> +		 W_EXITCODE(0,0) == 0.  */
> +	      store_waitstatus (&lp->waitstatus, status);
> +	      return 0;
> +	    }
> +
>  	  thread_dead = 1;
>  	  if (debug_linux_nat)
>  	    fprintf_unfiltered (gdb_stdlog, "WL: %s exited.\n",
> 

Another question.  This is probably unrelated to the current issue, since
the behavior was the same in 7.9, but I am encountering it while writing
the test.  When running the program without the &, when should the prompt
come back?

See this transcript: http://pastebin.com/qyba8Ucd

We see that the prompt comes back the first time an inferior exits, well
before the end of the execution of inferior #1.  I would think that this
is not what we want.  If I run my program synchronously, then the inferior
forks and then the fork child exits, do we really want to bring back the
prompt at this point?  I would think that we should only show it when
the initial inferior that was ran exits (or if some other significant
event, such as a breakpoint hit, of course).

Would you agree?


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