This is the mail archive of the
mailing list for the GDB project.
Re: [patch] gdbserver: Fix harmless crash for current-lwp-dead.exp
- From: Pedro Alves <pedro at codesourcery dot com>
- To: Jan Kratochvil <jan dot kratochvil at redhat dot com>
- Cc: gdb-patches at sourceware dot org
- Date: Thu, 8 Dec 2011 10:17:07 +0000
- Subject: Re: [patch] gdbserver: Fix harmless crash for current-lwp-dead.exp
- References: <20111208000500.GA8333@host2.jankratochvil.net>
On Thursday 08 December 2011 00:05:00, Jan Kratochvil wrote:
> On Fri, 02 Dec 2011 23:10:43 +0100, Jan Kratochvil wrote:
> > gdb.threads/current-lwp-dead.exp with local/native gdbserver will make
> > crash/coredump of gdbserver on its shutdown.
> > It is because gdbserver wants to kill the thread group leader - but in this
> > case there is no thread group leader, that is the purpose of the testcase.
> I was wrong here, the TID == PID LWP is not a thread group leader. It is from
> clone syscall without CLONE_THREAD, therefore with separate PID/TID. It just
> belongs to the same gdbserver `struct process' as it has been caught by
> As it is not a thread group leader waitpid already completed for it without
> any zombie LWP hanging, delete_lwp has been called. This is the difference
> from a thread group leader - that despite it has PID == TID the waitpid has
> already completed for it.
> > Hmm, do we leave the process zombie then? Should we always
> > waitpid it to reap it?
> There is nothing left from the kernel point of view.
When we fix gdbserver so that gdb.threads/leader-exit.exp doesn't
hang, then there will be. On native debugging, we end up reapping
the zombie leader in inf-ptrace.c:inf_ptrace_mourn_inferior. gdbserver
does not do that.
> Sorry for the confusion with "thread group leader". OK to check it in?